more on Solaris ACLs

Michael Davidson michael_davidson at pacbell.net
Tue May 29 15:41:48 GMT 2001


Gerald Carter wrote:
> 
> Ugghh...more ifdef'd code then I guess.  I need to test
> the Solaris ACL's some more for simple u/g/o ACLs.

I hope not - I tried very hard to keep Solaris and UnixWare
the same ...

> 
> > Anyway, the quick fix for this was just to *always*
> > let aclsort() recalculate the mask entry - at the time
> > I couldn't see any harm in this, and I still can't but
> > it just *may* be relevant.
> 
> I'll let Jeremy respond whenhe gets back.  The problem is
> that the mask must always be rwx in order to ensure the
> permissions set for the group.  Suppose that you wanted
> to set group 'A' to be rwx, but the mask was r-x.
> The NT security tab has no notion of masks, but smbd
> cannot violate the actual permissions on a file/directory.
> Therefore, what permissions you report to the user in the
> NT are not actually the ones the user gets.  And you have
> **no** way to inform the user of what the real problem is.
> 
> That is why the mask must always be rwx.
> 

I guess there is still something going on here that I don't
completely understand.

It isn't that the mask must always be rwx (although that
would work) - it must allow at least as much access as any
of the individual USER or GROUP entries or the GROUP_OBJ
entry, and this is what aclsort() does.

The mask calculated by aclsort() doesn't actually restrict
access to anything less than is already allowed by the
individual entries. Note that it isn't possible to modify
individual ACL entries - you have to change the entire list
- so any time you change an individual GROUP entry, for example,
you are going to recalculate the mask again - so everything
should be OK and the effective access permissions for
everyone should be what you wanted.

That's why I originally thought it was OK to recalculate
the mask unconditionally.

I agree that we should wait until Jeremy gets back or has a
chance to respond - I posted a patch earlier which was another
attempt at a "quick fix" for this - on second thoughts I'm
not so sure it's a good idea - probably better to leave it
intil we really understand what is going on.




More information about the samba-technical mailing list