[3102] in bugtraq
Re: /etc/shells (was Re: procmail)
daemon@ATHENA.MIT.EDU (Adam Bauer)
Fri Aug 9 12:30:21 1996
Date: Thu, 8 Aug 1996 15:21:18 -0400
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
From: Adam Bauer <abauer@gw.jmpstart.com>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
At 09:47 AM 8/8/96 -0400, der Mouse wrote:
>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".
I like the parallel database idea. That way it's not in /etc/passwd, which
in non-shadow-password machines is world-readable. Only suid root programs
can read who has what access - access information is 'on a need to know basis'.
How about /etc/access? (or /etc/useraccess?)
--------------
username:comment:ftp:use_dot_files:shell:chroot:etc:etc
--------------
username, comment self explanatory
ftp boolean - can user ftp to home directory?
use_dot_files boolean - should programs use user's dotfiles?
(like .forward, .profile, etc)
shell boolean - can user obtain an interactive login shell?
chroot boolean - should user be chrooted to his home directory?
(for the super-paranoid)
etc programs should allow extra fields and ignore them,
for future expansion
--------------
use_dot_files can prevent many, many hacks. Giving users interactive logins
without the ability to screw up .rhosts, .forward, .profile, .xauth, etc
would be great.
With shell, either the user can get in (command prompt), or he can't. If
the user tries to get in, disable his account, and make him call tech support.
Any other fields?
Now just convince everybody to use this.. <grin>
- Adam Bauer abauer@jmpstart.com JumpStart Systems
Computer and Network Administrator http://www.jmpstart.com
