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