Date: Thu, 28 Jul 2011 10:46:37 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: exorcistkiller <exorcistkiller@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Add setacl system call? Message-ID: <alpine.BSF.2.00.1107281042090.30580@fledge.watson.org> In-Reply-To: <1311658044945-4633662.post@n5.nabble.com> References: <1311496832217-4627557.post@n5.nabble.com> <alpine.BSF.2.00.1107250753370.51541@fledge.watson.org> <1311658044945-4633662.post@n5.nabble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1107281042090.30580>