Ftp daemon should not check /etc/shells !

[Stephen G. Simpson]

This is a complaint about the way ftp behaves on our local system of
networked Suns.  I'm not sure whether my complaint applies to all Bsd
systems, or only to SunOS.

When I try to ftp from the outside world into my own Sun account, our ftp
daemon uses a three-step procedure to "authenticate" the account.  One of
the steps is to compare my /etc/passwd entry with the /etc/shells file.
If my default login shell (as specified in my /etc/passwd entry) is other
than /bin/csh or /bin/sh and is not listed in /etc/shells, then the ftp
daemon assumes that the account is inauthentic, and refuses the
connection!  (See the man page for ftpd.)

In my opinion this behavior (on the part of the ftp daemon) is not in
accordance with the Unix philosophy that users are permitted to use a
shell of their choosing, provided the system administrator allows it.  In
my case, I want to use bash, the GNU Bourne Again shell, so I asked my sys
admin to change my default login shell (as specified in my /etc/passwd
entry) to bash.  He very kindly did so, but without adding a line to
/etc/shells.  (Adding such a line would allow any user to change his own
default login shell to bash, and it is not clear that we want to allow
this.)  All of this is in accordance with the man page for passwd -s.
But, ftp doesn't like it and balks.

In my opinion, this is a bug in ftp rather than in the /etc/passwd
procedure.  Ftp should realize that the system administrator may want to
change a user's default login shell to something unusual without putting a
corresponding line into /etc/shells.  It is obnoxious of ftp to assume
that an account with an unusual shell (not listed in /etc/shells) is ipso
facto illegitimate.

Please post your comments and also e-mail them to me, as I don't usually
read all of these newsgroups.