On Mon, 25 Jul 2011, exorcistkiller wrote:
Another question while I'm reading the code. In ufs_acl.c, in static int
ufs_getacl_posix1e(struct vop_getacl_args *ap), you commented: As part of
the ACL is stored in the inode, and the rest in an EA, assemble both into a
final ACL product. From what I learned from Kirk's book, ACLs are supposed
be stored in extended attributes blocks. So what do you mean by "part of the
ACL is stores in the inode"? I know extended attributes blocks data can be
addressed by inode, but how to get ACL directly from the inode?
POSIX.1e ACLs are defined as an extension to permissions: additional user
entries, group entries, and a mask entry supplement the existing owner, group
and other permission bits. Both the APIs and command line tools allow the
portions of the ACL representing permission bits to be directly manipulated.
For the purpose of the UFS implementation (and I suspect this to be common in
other implementations as well), we keep the owner/group/other bits (or
sometimes the mask bits) in the existing inode permissions field. All
additional entries are stored in the extended attribute. This has some nice
properties, not least:
(1) stat(2) on the file still only needs look at the inode, not the extended
attributes, making it faster.
(2) chmod(2) can be implemented by writing out only the inode, also faster.
(3) Files without extended ACLs don't need extended attributes stored.
The inclusion of a "mask" field in POSIX.1e is motivated similarly: it is what
allows stat(2) and chmod(2) to not touch extended ACL fields.
This is what the commend means by part of the ACL being stored in the inode,
and part in the extended attribute: any areas of an ACL that are actually
permission mask entries go in the existing mode bits in the inode for
efficiency reasons.
Robert
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
