OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1996: Re: /etc/shells (was Re: procmail

Re: /etc/shells (was Re: procmail

Jauder Ho (jauderhonetcom.com)
Thu, 8 Aug 1996 10:49:33 -0700 

        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
>
>                             mousecollatz.mcrcim.mcgill.edu
>                     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D
>