/etc/shells (was Re: procmail)

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

If I might spin off a new thread from this one....

> > Sendmail disallows this short things by not allowing pipes in
> > .forward if user have not valid shell (listed in /etc/shells).
> The problem there is that for an 'ftp only' account, the shell has to
> be in /etc/shells, or FTP will not work (with most FTP servers).

The problem here is, as I see it, that /etc/shells is all wrong.

I first saw /etc/shells as a response to the "chsh to a shell
containing colons and newlines" problem.  It worked for that, kind of,
but was way overkill, breaking the "the shell is just another program"
philosophy by preventing people from chshing to arbitrary shells of
their own creation.

Then it got overloaded by sendmail and ftpd and probably others as a
way of testing "is this user a real user or is it a pseudo-user that
should be denied this service".  As we're seeing here, the sets

- set of users corresponding to humans
- set of users who may use ftp
- set of users who may use pipes in .forward files

overlap but are not identical, at least for enough sites that making
/etc/shells serve for all is not a satisfactory solution.  And there
are more sets that I could have listed above, making it even less
satisfactory.

I can see only two solutions.  One would be to make each service
maintain its own list of users that are forbidden (or, alternatively,
allowed); the other would be to extend the passwd database (or,
equivalently, maintain a parallel database) so as to allow tagging each
user with arbitrary flags like "ftp access allowed" or "mail forward to
pipe forbidden".

Anyone have any comments on either, or any other alternatives to
suggest?

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu
                    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D