From nobody@FreeBSD.org  Tue Apr 20 15:07:35 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 265DA106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Apr 2010 15:07:35 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 150768FC1B
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Apr 2010 15:07:35 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o3KF7Yvj006146
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Apr 2010 15:07:34 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o3KF7Ydf006145;
	Tue, 20 Apr 2010 15:07:34 GMT
	(envelope-from nobody)
Message-Id: <201004201507.o3KF7Ydf006145@www.freebsd.org>
Date: Tue, 20 Apr 2010 15:07:34 GMT
From: Paul Hoffman <phoffman@proper.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: /usr/sbin/nologin should be in the default /etc/shells
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         145887
>Category:       conf
>Synopsis:       /usr/sbin/nologin should be in the default /etc/shells
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr 20 15:10:05 UTC 2010
>Closed-Date:    
>Last-Modified:  Wed Apr 21 17:10:02 UTC 2010
>Originator:     Paul Hoffman
>Release:        8.0
>Organization:
>Environment:
FreeBSD hoffman.proper.com 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan  5 16:02:27 UTC 2010     root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
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.
>How-To-Repeat:
Look at the default /etc/shells
>Fix:
Add /usr/sbin/nologin to /etc/shells.

>Release-Note:
>Audit-Trail:

From: Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>
To: Paul Hoffman <phoffman@proper.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: conf/145887: /usr/sbin/nologin should be in the default /etc/shells
Date: Wed, 21 Apr 2010 12:31:03 -0400

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

From: Paul Hoffman <phoffman@proper.com>
To: Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: conf/145887: /usr/sbin/nologin should be in the default
 /etc/shells
Date: Wed, 21 Apr 2010 09:39:54 -0700

 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
>Unformatted:
