Subject: RE: Access Control Lists
To: None <firstname.lastname@example.org>
From: Gordon Waidhofer <email@example.com>
Date: 05/05/2006 13:08:19
Pavel Cahyna wrote
> On Wed, May 03, 2006 at 08:49:10AM -0700, Bill Studenmund wrote:
> > > What have subfiles to do with ACLs?
> > Where do you think we put them? :-)
> > As Elad noted, we need a STRONG way to associate the ACL with
> the rest of
> > the file, and subfiles-for-storage are a good option.
> Subfiles are intended to be opaque, not interpreted by the kernel. At
> least that's what I got from Gordon Waidhofer's posts and presentations on
> this topic.
> Also, are you aware of any other system where ACLs are mapped to subfiles?
> Aren't extended attributes a better option?
Jason Thorpe wrote
In principal, I concur with Jason. ACLs are
Bill's conjecture that something subfile-like may
provide on-disk representation has merit. Both NTFS
and Solaris UFS do something like this.
One must separate the idea of semantics and API
from the idea of on-disk representation.
Subfiles are opaque and arbitrary sized.
(Extended) attributes are meaningful and
are acted upon by get/set. Please see page 51 of
for classification of subfiles and attributes.
The same presentation shows how some
different file systems handle on-disk
representation. Implentations can influence
semantics, and weaker implementations end
up requiring heavy address or being abandoned
I believe getxattr()/setxattr() is the right API
for (Extended/New/Legacy) attributes. Attribute
manipulation is becoming more akin to ioctl().
For example, there is contemplation of operating
on both POSIX ACLs and NFSv4 ACLs through getxattr()/setxattr()
and the right thing happens whatever the underlying
ACLs are at the time. To be clear, I can ask for the
NFSv4 ACL on a file system that is using POSIX ACLs.
Or I can set the POSIX ACL on a file system that is
using native NFSv4 or NT ACLs. NFSv4 servers/clients
have to do this translation anyway, so why not incorprate
it in a way that makes things easier