> At 02:55 PM 3/9/00 -0700, Brook Milligan wrote:
   > >Second, validshell() in addnerd.c uses getusershell() (which reads
   > >/etc/shells) to check the argument of -s against.  /sbin/nologin is
   > >not in /etc/shells, so this also fails.  Two possible fixes:  1) add
   > >an explicit check for /sbin/nologin; 2) add /sbin/nologin to
   > >/etc/shells.  Should either of these be added to addnerd?
   > 
   > Adding /sbin/nologin to /etc/shells would make sense in that many of us 
   > want to add no-login accounts to our systems. Given that the current 
   > password file comes with /sbin/nologin for many of the accounts, I don't 
   > understand why it's not already in /etc/shells.

   someone correct me if i am wrong here, but isnt a shell no in /etc/shells
   one of the checks ftpd does to see if ftp'ing to that users is aloud?

Exactly.

From man ftpd:

           3.   The user must have a standard shell returned by
                getusershell(3).  If the user's shell field in the password
                database is empty, the shell is assumed to be /bin/sh.

A good reason for it not being in /etc/shells.  That was why I asked.
It is not obvious that we want /sbin/nologin in /etc/shells.

But it seems we need a method for addnerd to create an account that
cannot be used for logins.  Do we want a special case in addnerd to
allow one to create an account (like majordomo) with /sbin/nologin as
a shell?

Or should we only allow "real" shells with addnerd and disable the
account through the password (which still requires either a long set
of *s or a modification to addnerd to accomplish).

More guidance from developers would be appreciated.

Cheers,
Brook