From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 24 22:26:33 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D640637B404 for ; Thu, 24 Apr 2003 22:26:32 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E606643FDF for ; Thu, 24 Apr 2003 22:26:31 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.9/8.12.9) with SMTP id h3P5Qk9S064112; Fri, 25 Apr 2003 01:26:47 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 25 Apr 2003 01:26:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: ouyang kai In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@FreeBSD.org Subject: Re: some questions about ACL implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2003 05:26:33 -0000 On Tue, 18 Mar 2003, ouyang kai wrote: > I am reading the ACL implementation based FreeBSD5.0 release. I have some > problems, please help. Sorry about not answering sooner, I missed your message in my rather excessive mailbox. > 1. the 'extattrctl initattr -p / 388 posix1e.acl_access' command: why the > size is 388. the 'ufs_extattr_header' size is 12 and the 'acl' is 324, so > the sum is 336. paprika:~/freebsd/tmp/acl> ./acl sizeof(struct acl) == 388 At least on my box ACL structures are 388 bytes, hence the size above. ufs_extattr_header should be excluded from the EA header size for UFS1, but if it's not, please let me know. In theory, if you initialize a UFS1 backing file and request storage for 20 byte EAs, it should reserve enough space for a complete 20 bytes of meta-data. > 2. what is the relationship of ACL_GROUP_OBJ and ACL_MASK? If I do not > set the ACL EA, we can not get the information of 'ACL_MASK'. ACL_MASK > represents what? The relationship between the group bits and the mask is "special" in POSIX.1e -- I'll refer you to the document for details, but I can give the high level idea here. The concept is that some applications understand only base permissions and umask, and that you want them to operate safely. If you do *not* have an extended ACL, then permissions should behave exactly as if you didn't support ACLs. If you do have an extended ACL, then you *must* have a mask, and when operations like stat(), chmod(), and umask act on ACLs, the group bits in the permission set are treated as though the affect the mask and not the group entry. For example, if an extended ACL is present on a file, stat() will replace the normal group permissions with the mask permissions, and chmod() will change the mask rather than the group permissions. Since the mask places an "upper bound" on the rights described by the extended ACL, this makes chmod/stat/... conservative from a permissions perspective. Regarding the creation mask: some systems choose to override the umask with the ACL mask, and some systems choose to intersect the two. Right now, we intersect since that's more conservative, but given that most mainstream systems either use the mask or are switching to it (Solaris, Linux, IRIX is switching), we will probably want to take the override approach. I have local patches that do most of that in the FreeBSD perforce server, and I had hoped to merge them by 5.1. Unfortunately, I'm much more time-constrained than I had hoped, so that work is currently stalled. The basic thrust is that the logic for combining the mask and requested creation mode has to be pushed into per-file system code, so you pass the mask into each creation VOP as well as the mode, not the intesection of the two. This touches all the file systems, so is fairly labor-intensive to implement. While it is less conservative than the intersection model, it is quite useful, since it permits default ACLs to force permissions/ACLs to be more open than the umask requests, which is good for "group project" sorts of environments. When we do implement these semantics, we'll probably support conditional use of either model based on some flag or criteria (perhaps compile-time, perhaps mount-time). > 3. "As part of the ACL is stored in the inode, and the rest in an EA, > assemble both into a final ACL product. Right now this is not done very > efficiently.", Do you any viewpoint about that? How we can improve the > efficiency? The biggest single performance improvement for ACLs was to move to UFS2, which dramatically improves the performance of EA operations. To get some further improvement, we should use one of the in-inode flags to be a weak consistency flag suggesting the presence of ACL data in the EA block, so that we can avoid an EA read if none is present. Weak consistency is required because soft updates cannot guarantee that two independent block writes must have ACID properties, it can only guarantee ordering. Therefore the flag should offer the possibility of false positives rather than false negatives :-). It would be relatively easy to add this support, but if doing so, we'd want to have convincing performance numbers that suggest it was useful. We've seen the vast majority of cost go away with UFS2, so it might not be needed. > 4. about ACL based on UFS2, do the ACLs of an inode store di_extb? Could > you introduce the ACLs' management on UFS2? UFS2 fully supports ACLs; in fact, we recommend UFS2 over UFS1 for ACLs because it's much faster and has better failure modes. UFS2 ACLs are stored in the EA extent pointed to by the inode, require less administrative overhead (since you don't have to configure EA backing files), etc, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories