[cifs-protocol] MS-SMB2/MS-FSA: setting SD inherited ACL flag "DACL Auto-Inherited" (DI)

Ralph Boehme slow at samba.org
Mon May 10 07:33:51 UTC 2021


Hello dochelp,

I've noticed that a wellknown behaviour with regards to ACL control 
flags semantics seems to be undocumented. At least, I couldn't find any 
reference that would explain the behaviour of a Windows SMB server.

Fwiw, Samba implements the same behaviour since many many years.

What I'm observing is that when setting an SD on a file or directory, 
the resulting value of the flag "DACL Auto-Inherited" (DI) depends on 
the values of both "DACL Auto-Inherited" (DI) and DACL Computed
Inheritance Required (DC).

Only if DI and DC are set in the client SD, the resulting SD will have DI.

Following along MS-SMB2 and MS-FSA I can only find the following 
applicable sections:

   MS-SMB2 3.3.5.21.3 Handling SMB2_0_INFO_SECURITY

   7. The server MUST call into the underlying object store to set
   the security on the object.<377>

   <377> Section 3.3.5.21.3: Windows performs SMB2 SET_INFO
   SMB2_0_INFO_SECURITY processing via Server Requests Setting
   of Security Information [MS-FSA] section 2.1.5.16.

   MS-FSA 2.1.5.16 Server Requests Setting of Security Information

   "... . The object store MUST set Open.File.SecurityDescriptor
   to InputBuffer."

I'm reading this as "the object store must store the unmodified SD 
received from the client ".

Can you please check if the observed behaviour is indeed missing from 
the documentation and should be added?

Thanks!
-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20210510/e522d780/OpenPGP_signature.sig>


More information about the cifs-protocol mailing list