What's next for Samba ?

tridge at samba.org tridge at samba.org
Thu Nov 13 23:01:46 GMT 2003

 > If?  You can be damn sure some of us want it :)  I might or might not 
 > get to work on it officially, but I'm sure there are many others 
 > interested in ACL mappings between Windows and Posix (1003.1e draft 
 > 17 I presume)

ok, basic idea is to store the ACLs twice. They will be stored once in
NT format in a posix extended attribute and once as a translated posix
ACL as a real posix ACL. Along with the NT ACL in the extended
attribute we also store the checksum of the translated posix ACL.

Then we do the following:

 * when a windows client stores a NT ACL we translate the NT ACL to a
   posix ACL and calculate a checksum on the posix ACL. We then put
   the translated posix ACL on the file and store the NT ACL along
   with the checksum in an extended attribute.

 * when a windows client wants to access a file (including the above
   case of storing an ACL) then we retrieve the NT ACL and the posix
   ACL from the file. We re-calculate the checksum on the posix ACL
   and compare to the stored checksum. If it hasn't changed then we
   know that the NT ACL is correct. In that case we interpret the NT
   ACL in user space to determine if the operation is allowed. If the
   posix ACL has changed on disk then we wipe the NT ACL from the
   extended attribute and allow the system posix ACL to be the sole
   determination of access.

 * when a posix application accesses a file then it will just see the
   posix ACL and obey it. If it modifies the ACL then then checksum
   will no-longer match and the NT ACL will no longer be used.

There are many varients on this. For example, we may use the whole
posix ACL as the checksum (to prevent checksum collisions). We could
also add a timestamp into the extended attribute which gives the
create time on the file when the posix attribute was stored. If we can
live with the race conditions (I suspect we won't be able to) then we
could use that timestamp as a faster pre-discriminant for if the posix
ACL has changed.

We will also have the choice in Samba of whether we honor both the
posix ACL and the windows ACL or just the windows ACL, in a similar
fashion to the "posix locking = yes/no" option. The default should be
to honor both, but if you set "posix acls = no" then the code would
not bother storing a posix ACL and the sole determinate of access
would be the user space ACL code in Samba.

The overall aim is to give perfect ACL semantics for both windows and
posix clients. When you have mixtures of posix and windows clients
operating on the one file then you minimise the transition points,
which should minimise surprises.

The biggest part of this work would be to add authorization checks in
all the places they are needed in Samba. Right now Samba relies solely
on the OS to provide those checks, but we would have to duplicate all
of that in smbd. Thats quite a large task.

Cheers, Tridge

More information about the samba-technical mailing list