From owner-freebsd-bugs@FreeBSD.ORG Wed Apr 21 23:01:29 2010 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D025E1065670 for ; Wed, 21 Apr 2010 23:01:29 +0000 (UTC) (envelope-from freebsd-bugs-local@be-well.ilk.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1B88FC12 for ; Wed, 21 Apr 2010 23:01:29 +0000 (UTC) Received: (qmail 32209 invoked from network); 21 Apr 2010 22:34:47 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Apr 2010 22:34:47 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id E3A9350885; Wed, 21 Apr 2010 18:34:44 -0400 (EDT) From: Lowell Gilbert To: freebsd-bugs@freebsd.org References: <201004201507.o3KF7Ydf006145@www.freebsd.org> <44vdbk6a48.fsf@be-well.ilk.org> Date: Wed, 21 Apr 2010 18:34:44 -0400 In-Reply-To: (Paul Hoffman's message of "Wed\, 21 Apr 2010 09\:39\:54 -0700") Message-ID: <44mxww5ta3.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 23:01:30 -0000 Paul Hoffman writes: > At 12:31 PM -0400 4/21/10, Lowell Gilbert wrote: >>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). > > Sorry, I don't understand what you are saying. I thought the fact that > /usr/sbin/nologin exists and is executable is so that it *could* be > listed in /etc/shells safely. I'm not really an expert, but I believe you are incorrect. The documentation for nologin(8) says otherwise ("intended as a replacement shell field for accounts that have been disabled"). Furthermore, other functionality is available to accounts with valid shells. System accounts are given nologin as a shell for this reason. Putting nologin into shells by default would open up, for example, the "bind" user to be able to FTP into the box on many existing systems. This would Not be Good. > /usr/sbin/nologin is a log better than > giving the user a shell that does not exist. Somewhat, yes. >>> 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" >>[ > > Errr, we would need to be more explicit than that. I see nothing in the man pages for procmail or procmailrc that explains this well. And, in my case, it wasn't .procmailrc, but .vacation. Please feel free to improve on my suggestion. "The account will be disabled" might be a more encompassing statement to make.