[Fwd] default acl for directory

[Robert Watson]

I'll have to look some more at the umask issues you've raised -- in
particular, it may make sense to look at what some of the other
implementations have done.  However, I think I can address the issue of
the stat()/chmod() results you're running into (see below).

On Wed, 27 Nov 2002, Dancho Penev wrote:

> >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
> 
> I'm in agreement with yours argument that in this case inode group
> permission and mask are one thing but if you take a look at primer that
> I give, if we don't update group entry as result we will have two
> different permissions for owner group in inode and in acl. 

I guess I'm not sure I quite follow.  There are two layers to the
implementation: in the file system itself, we speak of inode permissions
and an extended ACL stored in extended attributes.  At the layer of the
user process, we speak of the results of stat() and acl_get_file().  Our
reading of the spec suggested that stat() should return the ACL mask in
the group fields of the mode_t, or return the group permissions if there's
no ACL mask.  When you say there are different permissions in the inode
and the ACL, I think what you're observing is that when there is a mask,
you see the mask and not the group owner entry.  This is intentional --
stat() and chmod() can't express the scope of the ACLs, so they end up
literally retrieving and setting the file owner and other fields.  When it
comes to the group field, if they provide, in modification, the ability to
set a conservative restriction (masking all non-owner/non-other entries),
and they provide a liberal interpretation when you retrieve. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message