From owner-freebsd-current@FreeBSD.ORG Sun Aug 10 07:19:04 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEA8A37B401 for ; Sun, 10 Aug 2003 07:19:03 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 324DA43FBD for ; Sun, 10 Aug 2003 07:19:03 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h7AEIfAL018672; Sun, 10 Aug 2003 10:18:41 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h7AEIfVj018669; Sun, 10 Aug 2003 10:18:41 -0400 (EDT) Date: Sun, 10 Aug 2003 10:18:41 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Branko F. Gracnar" In-Reply-To: <001701c35f47$b9379450$fac8a8c0@MORDOR> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 5.1-R acl problem (again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2003 14:19:04 -0000 On Sun, 10 Aug 2003, Branko F. Gracnar wrote: > Thanks for quick and very informative answer. > > You're right about getfacl -d (i used linux + acl patch before, where > default acls are displayed without any arguments and i didn't read > getfacl man page). Yeah -- the Linux tool implementation is based more on Solaris than on POSIX.1e. That has some upsides, and some downsides. I believe there's an environmental variable you can set on Linux to cause the getfacl/setfacl to behave in strict accordance with the spec ("POSIXLY_CORRECT" or the like). > Thanks alot again. Sure. > But there is one thing, i don't understand. > > if i issue the following command: > > setfacl -dm u::rwx,g::rx,o::---,u:branko:rwx,m::rwx directory > > and then create file under that directory, why getfacl reports: > > #file:a/c > #owner:0 > #group:0 > user::rw- > user:branko:rwx # effective: r-- > group::r-x # effective: r-- > mask::r-- > other::r-- > > why is mask just 'r' ?! One of the contentious issues in the design of POSIX.1e was how to set the protections on a new object. There are three variables of interest: the creation mode requested by a process, the umask of that process, and the default ACL on the parent directory where the object is being created. In 5.0-R and 5.1-R, we combine them as follows: we mask all elements of the creation mode using the umask; we then combine the ACL and combined mode by converting the default ACL to the access ACL on the new object and overwriting the access ACL fields with the equivilent fields in the mode. So in the above example, a mask of r-- is likely a result of the creation mode and umask having a group mode of 4. In 5.1-CURRENT, we recently switched these semantics to perform a further intersection of rights in the ACL, rather than a replacement of rights. The result is that if the mask in your default ACL is --- and the combination of creation mode and umask is r--, you get a mask of --- in the final access ACL. This implements the algorithm in the POSIX.1e spec to the letter: at some point, these semantics got changed during a retrofit of the ACL code, and it wasn't picked up (this might actually have been after 5.0 but I haven't checked the logs). I'm currently in the throes of implementing a mode of operation which uses the Solaris/Linux algorithm, which works in the following manner: if an default ACL is being used to create a new object, the default ACL replaces the umask, rather than combining with it. This allows directory default ACLs to override the umask locally, producing more liberal rights, which may be what you're expecting. This is a violation of the spec, but it's a common violation due to its utility (POSIX.1e doesn't allow the "create more liberal protections" because it was deemed unsafe). I hope to finish prototyping this and get a patch out to the current@ list in the next couple of weeks. The complication is that currently, the umask and requested creation mode are combined at the system call layer, above VFS, so we need to expose them separately on the entry to the file system. The result is that all file systems would now have to combine the two elements, and it touches a lot of code. Hope this information is useful, and gives you a good picture of where we're going. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories