Re: /etc/shells (was Re: procmail

[bonomi () delta eecs nwu edu (Robert Bonomi)]

On Thu, 8 Aug 1996, der Mouse wrote:
> 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?

And Jauar Ho replied:
+         how about extending the passwd fields one more after the shell so
+ that mine would be something like
+       auderho:x:1298:1:Jauder Ho:/export/home/jauderho:/usr/local/bin/tcsh:tf
+ with single letters representing different options , we can have 62 if we
+ use all the numerals , upper and lower cases of the alphabet.  So let's say
+ that t stands for telnet allowed, ftp allowed ...
+
+ this allows pretty fine grained control over users.


Extending (logically) the password database seems reasonable.

I'd nominate /etc/shadow (/etc/passwd.adjunct, or whatever) as the
appropriate place.  All of the 'concerns' are "potential abuse by
_priviledged_ programs", so, keep the stuff where -only- a priviledged
program can access it.

I would suggest that -direct- encoding of capabilities, as Jauar proposed,
is a 'not good' idea.  It is _rare_ that one wants/needs to enumerate the
capabilities on a _per-user_ basis. Usually, one has certain _classes_ of
user, with common capabilites for the class.  This leads to the concept
of an "usercap" (??) file, structured a la 'termcap'/'printcap', and for
which the query tools already exist.  It's also general enough to allow
one to store *any* kinds of 'controls' -- booleans for 'capabilities',
numerics for quantitative limits, etc.