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

Lowell Gilbert freebsd-bugs-local at be-well.ilk.org
Wed Apr 21 23:01:30 UTC 2010


Paul Hoffman <phoffman at proper.com> writes:

> At 12:31 PM -0400 4/21/10, Lowell Gilbert wrote:
>>Paul Hoffman <phoffman at proper.com> 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.



More information about the freebsd-bugs mailing list