PROPOSAL: extend UNIX_INFO2 to mark existence of ACLs

[Steve French]

On Tue, 2008-01-22 at 20:11 -0600, Christopher R. Hertel wrote:
> James Peach wrote:
> > On Jan 22, 2008, at 3:46 PM, Christopher R. Hertel wrote:
> > 
> >> Jeremy Allison wrote:
> >>> On Tue, Jan 22, 2008 at 05:16:14PM -0600, Steve French wrote:
> >>>> There are systems which support Unix Extensions but do not support
> >>>> POSIX
> >>>> ACLs.
> >>
> >> Yep.  I'm working with one such currently.
> > 
> > I intended that this bit would be set by any server that understood the
> > UNIX_INFO2 info level and had a concept of (on-disk) ACLs the went
> > further than a one-to-one mapping of the POSIX permissions bits.
> 
> The SNFS file system does not support POSIX ACLs but does understand the
> POSIX permission bits.  The question of whether or not to support the Unix
> Extensions in general has been raised.
> 
> > From a client point of view, the bit is flagging whether there is any
> > more security information to fetch that isn't in the UNIX_INFO2
> > response. Whether the extra security information is a POSIX ACL or a NT
> > security descriptor doesn't mater all that much (ie. the server has to
> > unify these somehow anyway).
> 
> Actually not.  Yes, I've already had this discussion and I appreciated the
> points made, but under SNFS the POSIX and Windows access controls are kept
> separate.  The task I have been given is to extend the Windows semantics to
> CIFS clients.
I agree with Chris, a POSIX ACL is different from a CIFS ACL and the
difference does matter.  It is preferable to fetch the "native" ACL if
possible.   Unfortunately a Samba server will return a CIFS ACL (even if
the file system under it does not have such) but it will not necessarily
even be able to return a POSIX ACL (if the Unix CAP for that is off
e.g.).  Although I can agree with those who would consider NFSv4 and
CIFS ACLs close enough for this purpose, it seems like this bit should
either represent the presence of a POSIX ACL (only) and therefore be
meaningless if POSIX ACLs were not negotiated or we steal another bit so
we can decide which ACL to query - if we go to the trouble of extending
the protocol it does not seem to do much good to lose performance on the
Query of the ACL by having to query in many cases (remember that in many
cases the server may have files with different types of ACLs or subtrees
under the same share with different native ACL models)



> :
> >> The proposal is to overload the Permissions field in the structure
> >> returned by the UNIX_INFO2 call.
> > 
> > No, it's to define an extra bit in this field. The extra bit means
> > "there are security attributes that aren't represented here".
> >
> > #define UNIX_EXTENDED_SECURITY (1<<63) /* choose a less generic name! */
> > 
> > If a client sees this bit, it can query the security descriptor or fetch
> > the POSIX ACL, whichever it prefers. I expect that most clients that
> > support the UNIX extensions would simply fetch the ACL.
> 
> Whether it's overloading or not depends on the original intent of the use of
> that field, but I'm splitting hairs.  (I'm good at that.  :)
It is ok to "overload" them in this case, they are vaguely permission
related.