On Thu, 8 Mar 2001, Lord Isildur wrote:

> 
> this is because you dont need to go mucking around with the filesystem to 
> achieve this. the 'non supportive' people were right. 
> besides, this sort of thing has no place in the generic filesystem code, 
> nor in the FFS. Certain filesystems support acls, for example AFS, and
> those can coexist just fine with NetBSD. Leave such specificity in a 
> special filesystem implementation like AFS support, not in the generic fs 
> code or in the FFS. 
> This sort of thing is what groups were invented for close to 30 years 
> ago. 
> Isildur
> 


I have had this argument before and I feel you are wrong to claim
that ACL support is not required. Groups do not provide the granularity
of control that a user my wish to have in many modern IT working
environments.

They may want different groups to have different access rights to the
same file. Having to ask a sys-admin to create a new special group to
cope with each possible combination of groups only partially solves the
problem and it is not practice for a busy IT department. People make
decisions about who they which to have access to files when they
cerate them and may not know in advance nor have the insight to
request the sys-admin to create the groups they want. Even if this was
not a problem they may want "read/write" for some member of a group,
"read only" for other members of other groups, and no access to
everyone else. A unix file can not have more than one group, it a
fundamental restriction.

Note, it is also not possible to grant meta data privileges on a
file. You can only grant privileges on the files data. Granting a
specific user or group of users the rights to grant others
access can be useful. This is especially true when there are strict
rules about data sharing between projects and staff members, which 
can be very important in the commercial world. Another current
limitation is the in ability to grant restricted chown rights to
another user on an individual file. Not usually a requirement for
a unix user but it can be one for a samba system exporting files to NT
users.

Security is a responsibility of a modern OS. You can not rely on the
application layer to enforce it alone. Some companies have to work
with "protectively marked data" such files need to have mandatory
access control enforced on them so that they can not be accessed by
software that does not have the rights. In fact you should not even be
able to copy the file to a media location that does not also support
the Mandatory access control that it has.

These are real issues. The last one is a special case and I don't
know of a version of Unix that supports what I described, but the
issue of ACLs is supported (check my last posting) by several versions
of unix an NT.

I'm not saying it should be a part of FFS but to suport it you will
need a file system based on say FFS that has the extentions required.
Suport for these extentions in the kernel would also make the handling
of NTFS a little simpler too. 


--Sean