[3088] in bugtraq
Re: /etc/shells (was Re: procmail
daemon@ATHENA.MIT.EDU (Jauder Ho)
Thu Aug 8 14:42:41 1996
Date: Thu, 8 Aug 1996 10:49:33 -0700
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
From: Jauder Ho <jauderho@netcom.com>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <199608081347.JAA12332@Collatz.McRCIM.McGill.EDU>
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.
--Jauder
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?
>
> der Mouse
>
> mouse@collatz.mcrcim.mcgill.edu
> 01 EE 31 F6 BB 0C 34 36 00 F3 7C 5A C1 A0 67 1D
>
