Re: "valid shell"s

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Fri, 8 Feb 2008 13:30:56 -0500
"Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost> wrote:


> I think it was still a big assumption to make to use /etc/shells as
> a control for ftpd (i.e. that users who don't have "valid"
> interactive shells should also be denied the privilege of being able
> to "login" using ftpd).  However Unix admins being the lazy sort we
> are, having a short-cut to implicitly denying ftpd access to all
> "special" non- interactive users was, and usually still is, generally
> a safe default.  (I haven't checked the code, but I'm
> hoping /etc/ftpusers trumps /etc/shells these days now that the
> former has much more complex semantics than it originally had.)
>
The issue was uucp, plus a few other utility logins with no password or
a well-known password: games, sync, etc.  It's not so much a
non-interactive shell that's barred as special-purpose shells.  That
is, the special-purpose shells provided their own access control to
files and other system resources.  ftpd had no access controls, save
for the chroot for anonymous ftp, but it was *the* other way that
people could log in and gain file system access.  I've often thought
that there was a simpler solution than /etc/shells -- have the ftpd
login program invoke $SHELL/real-ftpd when you logged in.  If you had a
pseudo-shell, that wouldn't work, so no harm would be done.  It would
also separate the login section of ftpd from the commands, itself a
very good idea that I've written about elsewhere.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb