Date: Wed, 21 Apr 2010 16:34:10 -0700 From: Paul Hoffman <phoffman@proper.com> To: Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>, freebsd-bugs@freebsd.org Subject: Re: conf/145887: /usr/sbin/nologin should be in the default /etc/shells Message-ID: <p0624088cc7f53a5a8d7e@[10.20.30.158]> In-Reply-To: <44mxww5ta3.fsf@be-well.ilk.org> References: <201004201507.o3KF7Ydf006145@www.freebsd.org> <44vdbk6a48.fsf@be-well.ilk.org> <p0624086dc7f4d96fd620@[10.20.30.158]> <44mxww5ta3.fsf@be-well.ilk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:34 PM -0400 4/21/10, Lowell Gilbert wrote:
>Paul Hoffman <phoffman@proper.com> writes:
>
>> At 12:31 PM -0400 4/21/10, Lowell Gilbert wrote:
>>>Paul Hoffman <phoffman@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.
This sounds like the logic is that /usr/sbin/nologin is meant for system accounts only. If so, why is it offered by "adduser"?
>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.
That would only be true if you gave the "bind" user a password.
>
> > /usr/sbin/nologin is a log better than
>> giving the user a shell that does not exist.
>
>Somewhat, yes.
The problem is that many servers in the ports collection (such as mail access programs like qpoper) will only let clients connect if the client has a shell that is listed in /etc/shells. From a security standpoint, it would be obviously better to give these users the ability to act as clients but not to be able to log in using the shells that are listed by default (sh, csh, or tcsh).
It sounds like you are suggesting that these users should be given a *different* shell, and that shell be added to /etc/shells. Why would that be any better than adding /usr/sbin/nologin to /etc/shells?
Or, are you suggesting that all the servers in ports that rely on /etc/shells shouldn't? If so, why do we allow them at all?
--Paul Hoffman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0624088cc7f53a5a8d7e>