one of the fundamental ideas in the design of UNIX, which i think is 
every bit as relevant today as it was in the beginning, is that the UNIX 
filesystem does NOT have such compartmentalization and specialization of 
files, does NOT have semantic interpretation of files. A very important 
concept in UNIX is that files are just an arbitrary sequence of bytes. 
The system merely stores them. You can implement ACLs in a userland 
solution on top of UNIX, but please dont go putting interpretation of 
files into UNIX. There is only one special case in UNIX: a directory. 
One might argue, add ACL support to directories. But, in the design ofd 
UNIX, a more general mechanism was instead thought up, which can be used
for ACLs if one wishes: groups. 

Dont forget that a lot of the stuff people are trying to shoehorn into 
the kernel really belongs in userland. 

Isildur

On Thu, 8 Mar 2001, Robert Elz wrote:

>     Date:        Thu, 8 Mar 2001 13:55:49 +0100
>     From:        Frank van der Linden <fvdl@wasabisystems.com>
>     Message-ID:  <20010308135549.A2248@vaasje.org>
> 
>   | I think that most people are certainly interested in ACL support.
>   | Manpower would be a problem, though, someone has to stand up and
>   | actually do it..
> 
> I have this kind of less than half baked idea (so far anyway) to
> add "associated files" to inodes - that is, to allow a file to
> have almost any number of other kinds of data attached to it.
> 
> The data would be just another file, so in a way every file would
> be a directory, though probably not with names, but with types, that
> is, if some of the associated data was an ACL, then what the kernel would
> want is to find acls associated with this file, not to find "foobar".
> 
> Linking to a file this way would increase the inode ref count of course,
> so the named file could then be unlinked if desired.
> 
> There are a whole bunch of issues associated with this - and I'm not sure
> it would work, but the idea is basically fundamentally simple.
> 
> Actually making an ACL system on top of this ought then be fairly easy
> (assuming some kind of suitable ACL language can be designed).
> 
> Apart from ACLs, this could store stuff like dump/archive history,
> or macintosh type "forks" or almost anything else that it makes sense
> to have all linked together with a file.
> 
> kre
> 
>