From owner-freebsd-bugs@FreeBSD.ORG Wed Apr 21 16:40:05 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 983D0106566B for ; Wed, 21 Apr 2010 16:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB548FC12 for ; Wed, 21 Apr 2010 16:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3LGe5Ys020837 for ; Wed, 21 Apr 2010 16:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3LGe5iK020835; Wed, 21 Apr 2010 16:40:05 GMT (envelope-from gnats) Date: Wed, 21 Apr 2010 16:40:05 GMT Message-Id: <201004211640.o3LGe5iK020835@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Lowell Gilbert Cc: Subject: Re: conf/145887: /usr/sbin/nologin should be in the default /etc/shells X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lowell Gilbert List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:40:05 -0000 The following reply was made to PR conf/145887; it has been noted by GNATS. From: Lowell Gilbert To: Paul Hoffman Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: conf/145887: /usr/sbin/nologin should be in the default /etc/shells Date: Wed, 21 Apr 2010 12:31:03 -0400 Paul Hoffman writes: > If adduser offers it as a shell, it should be listed in /etc/shells; otherwise, this kind of error will nail admins. This is exactly what nologin is for. I wouldn't want to see all of the daemon-owning accounts starting to pass getusershell(3). > If it is decided not add /usr/sbin/nologin to /etc/shells, I propose that if someone tells adduser that that is a user's shell, adduser should have a warning that tells the admin that the shell they are adding is not in /etc/shells. It does have code for to disallow shells that aren't in /etc/shells or don't exist, but makes a special case for nologin (on the theory that that's the whole purpose of nologin). I suppose adding such a warning into the shell_exists() function would be okay, but I'm not sure what it would say. The usual way to handle your issue is to adjust the procmail configuration, not the account's shell. I think that setting SHELL to something useful (presumably /bin/sh) in the user's .procmailrc (or I think you could even put this in /usr/local/etc/procmailrc) would do the job. >>How-To-Repeat: > Look at the default /etc/shells >>Fix: > Add /usr/sbin/nologin to /etc/shells. How about changing adduser.sh along the lines of: 175a176,177 > else > info "if you want procmail to work with nologin > shell, adjust .procmailrc accordingly" [