Subject: Re: Security problem with pkgsrc/mail/majordomo
To: None <firstname.lastname@example.org>
From: Brook Milligan <email@example.com>
Date: 03/09/2000 15:32:50
> 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?
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
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.