From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 09:46:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D091065676 for ; Thu, 28 Jul 2011 09:46:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A16A18FC08 for ; Thu, 28 Jul 2011 09:46:38 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 50B8446B46; Thu, 28 Jul 2011 05:46:38 -0400 (EDT) Date: Thu, 28 Jul 2011 10:46:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: exorcistkiller In-Reply-To: <1311658044945-4633662.post@n5.nabble.com> Message-ID: References: <1311496832217-4627557.post@n5.nabble.com> <1311658044945-4633662.post@n5.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Add setacl system call? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:46:40 -0000 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