Bug 145887

Summary:	/usr/sbin/nologin should be in the default /etc/shells
Product:	Base System	Reporter:	phoffman
Component:	conf	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Open ---
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description phoffman 2010-04-20 16:10:05 UTC

I just migrated to a new machine, and a bunch of mail was bounced until it was reported to me by the users. It turns out that procmail won't copy mail to a file unless the user's default shell is listed in /etc/shells. However, /usr/sbin/nologn (which is what many of us use for mail-only users) is not in /etc/shells by default, even though it is offered as a shell by adduser.

If adduser offers it as a shell, it should be listed in /etc/shells; otherwise, this kind of error will nail admins.

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.

Fix: 

Add /usr/sbin/nologin to /etc/shells.
How-To-Repeat: Look at the default /etc/shells

Comment 1 Lowell Gilbert 2010-04-21 17:31:03 UTC

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).

> 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"
[

Comment 2 phoffman 2010-04-21 17:39:54 UTC

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. /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
>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.

--Paul Hoffman

Comment 3 Eitan Adler freebsd_committer

2017-12-31 07:59:55 UTC

For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped