conf/145887: /usr/sbin/nologin should be in the default /etc/shells

Paul Hoffman phoffman at
Wed Apr 21 17:10:05 UTC 2010

The following reply was made to PR conf/145887; it has been noted by GNATS.

From: Paul Hoffman <phoffman at>
To: Lowell Gilbert <freebsd-bugs-local at>
Cc: freebsd-gnats-submit at
Subject: Re: conf/145887: /usr/sbin/nologin should be in the default
Date: Wed, 21 Apr 2010 09:39:54 -0700

 At 12:31 PM -0400 4/21/10, Lowell Gilbert wrote:
 >Paul Hoffman <phoffman at> 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. /usr/sbin/nologin is a log better than giving the user a shell that does not exist.
 >> 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
 >> Look at the default /etc/shells
 >> Add /usr/sbin/nologin to /etc/shells.
 >How about changing along the lines of:
 >>               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.
 --Paul Hoffman

More information about the freebsd-bugs mailing list