Bugtraq mailing list archives
Re: /etc/shells (was Re: procmail)
From: proff () suburbia net (Julian Assange)
Date: Fri, 9 Aug 1996 06:06:49 +1000
-----BEGIN PGP SIGNED MESSAGE----- On Thu, 8 Aug 1996, Eugene Bradley wrote: : I kinda like der Mouse's latter idea. In fact, here are some ideas : for the flags that can be used in a passwd database that root can : edit in as necessary. I don't know if some UNIX OSes support this : feature currently in the form of kernel flags; this is an idea I have : off the top of my head. There are *IX implementations where the master passwd file (/etc/shadow, /etc/master.passwd, etc.) is a so-called opaque file and the /etc/passwd "standard" format file is generated from it. They could easily be put into additional flags in the opaque passwd file. Note that a *IX kernel doesn't touch passwd files; only user mode code changes user ID's and works with the passwds.
The /etc/passwd scheme is botch. /etc/passwd should be merely one view of a relational database which contains information about all users. NIS+ attempts to do this, but does it poorly. IMHO the strength of unix was that nearly everything was a file system object. Hardlinks were a primitive attempt at multiple views of the same object. Symbolic links are a kludge, because they point to a view of an object, rather than the object itself. Any permission or name-space scheme which doesn't use the file system is also kludge, because it ruins the file-system encapsulation all objects. BSD networking functions are an example. Everything should be a file system object and it's security should be dictated by the file system. The reason why linux's /proc is so popular is because it uses the filesystem to create a view of kernel objects. When introducing a new name-space, or permission scheme, it should be given a file-system view. If the file-system is not something that easily accomodates such objects, then the file system should be upgraded. The idea is that the file-system provides a consistant name-space and permission-space to all objects addressable under unix. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff () suburbia net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff () gnu ai mit edu | FAX +61-3-98199066 | 0619737CCC143F6DEA73E27378933690 | +---------------------+--------------------+----------------------------------+
Current thread:
- /etc/shells (was Re: procmail) der Mouse (Aug 08)
- Re: /etc/shells (was Re: procmail Jauder Ho (Aug 08)
- Re: /etc/shells (was Re: procmail BriaNeiLevine (Aug 08)
- Re: /etc/shells (was Re: procmail Douglas Song (Aug 08)
- Re: /etc/shells (was Re: procmail Junya Ho (Aug 08)
- Re: /etc/shells (was Re: procmail Shaun Lowry (Aug 09)
- <Possible follow-ups>
- Re: /etc/shells (was Re: procmail) Rob Payne (Aug 08)
- Re: /etc/shells (was Re: procmail) Eugene Bradley (Aug 08)
- Re: /etc/shells (was Re: procmail) Valdis.Kletnieks () vt edu (Aug 08)
- Re: /etc/shells (was Re: procmail) Todd Vierling (Aug 08)
- Re: /etc/shells (was Re: procmail) Julian Assange (Aug 08)
- Re: /etc/shells (was Re: procmail) Theo de Raadt (Aug 08)
- Re: /etc/shells (was Re: procmail) Sam Quigley (Aug 08)
- Re: /etc/shells (was Re: procmail) W Lee Nussbaum (Aug 08)
- Re: /etc/shells (was Re: procmail) Douglas Song (Aug 08)
- Re: /etc/shells (was Re: procmail Jauder Ho (Aug 08)
- Re: /etc/shells (was Re: procmail) Adam Bauer (Aug 08)