On Thu, 4 Dec 1997, Paul Evans wrote:

> 
> Here goes my $0.02..
> 
> I'd favor a two-tier approach where security and user associations
> are isolated. 

> Security would be based upon an ACL virtual file. Similar to procfs.
> That is, a special directory of ACL's which are hashed etc. The only
> extension to an Inode would be the associated Inode if any of it's
> ACL file on the special ACL VFS. This would allow incredibly complex
> security with the advantage that ACL's are centrally manageable in a
> manner similar to /etc/group without textfile overhead. 

Etc group has a big drawback. How does a group administrator/leader
add or remove people from the group without asking a unix adminstrator
to do it. Will this difficulty persist in the idea above or cna you
have multiple group managers with different levels of priority or
managament access over a group ?

> It would destroy the idea of a file being a file. We'd have a NT/VMS
> like registry that's mounted as a special dir tree. (or maybe not
> mounted.) I kinda feel like /etc/ should be nothing more than a
> "procfs" like translator interface to a special file. A registry
> that's got an ASCII in/out under /etc/ and a formatted binary on
> under /registry (I'm sure a lot of people didn't want to hear that!
> ;)) 

It may be an  advantage if cisco/M$ and the reset have their way with
network directory services.

> 
> To make a long story short, we need an analogue of the HURD
> translator mechanism and a separate ACL mechanism,
> 
> I think ACL's are too big.and complex to really be part of the
> file-system, they should be part of the "system" as such.
>

That may be true but we should deffinetly have file system hocks to
enable a clean and efficent management of such information.

--Sean