On Thu, 8 Mar 2001, Lord Isildur wrote:

> 
> 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. 
> 

I never suggested we change the conecpt that to unix a file is an
arbitary sequence of bytes. I ask to extened the unix security
conecpts to incldue ACLs. Security is an OS service that
applications are "forced" to obey. Unix deals with the conecpt of a
file it doesn't care what is in it but it does care who can read it or
write to it. To enforce it has to be in the file system that you
which this opion to be able with and it has to eb suporetd by the
kernel. If you want to control what bits of an individual file 
someone can read and write to then that is a data format standard
issue and best handled by an application.

As for non-ACL meta data, MIME etc well that I will accept is an
application layer task but its not always easy to precess and data
file quickly and get all the meta data about you need. I'm not saying
we should add support for storing two block lists with each inode
(data blocks, and meta data blocks) but I can see how it would provide
a simpler unified mechamism for application. I do agree though that
this is not in the spirit of UNIX.

--Sean