Date: Mon, 25 Nov 2002 10:41:21 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Dancho Penev <dpenev@mail.bg> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: default acl for directory Message-ID: <Pine.NEB.3.96L.1021125103243.31301A-100000@fledge.watson.org> In-Reply-To: <20021123160418.GA252@earth.dpsca.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Nov 2002, Dancho Penev wrote: > I was played with acl and specially default acl for directories at my > FreeBSD-CURRENT machine with UFS2 filesystem and some questions appears > to me: > > 1. How about default acl permission to override umask? Is that the idea > who isn't yet implemented or you have opinions against that. My reading of the POSIX.1e spec was that umask would continue to mask ACLs in the same manner it masked permissions. However, you're welcome to re-read the spec, or e-mail the POSIX.1e mailing list, and let us know if the result looks different to you :-). The idea, btw, I suspect, is that this provides maximum compatibility for applications that understand only permissions and not full ACLs. > 2. What are reasons to update ACL_MASK entry (if exist) or ACL_GROUP_OBJ > entry (if mask doesn't exist) but not both in ufs_sync_acl_from_inode()? > > It's true that reverse function ufs_sync_inode_from_acl() uses the same > logic but take a look at follow situation: This is another POSIX.1e-ism, and our implementation is based on a reading of that draft spec. If you want to give it a reading, or query the POSIX.1e list for clarification, I'd welcome any investigation of the issue. My understanding is that the goal of the mask is to match the semantics of the permissions group entry in the traditional inode protections for applications that don't understand ACLs. I.e., suppose an application creates a file, then chmods it 0600 -- the application wants the owner, and only the owner, to have read and write access. If a mask entry is present (and it is required if there is ever any other extended entry), then we update the mask entry in the chmod(), which in effect leads to the same result: it masks all entries but the owner and the other entry. If there's no mask entry, then there are no extended entries, so we actually change the group protections. If the implementation of this logic looks incorrect, please let me know. Also, feel free to read the spec and e-mail the list and see if this actually is a sensical interpretation of the spec. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021125103243.31301A-100000>