The Samba-Bugzilla – Bug 8638
ACLs for structural classes without defaultSecurityDescriptor are broken
Last modified: 2014-11-27 14:53:56 UTC
If a class definition doesn't have a defaultSecurityDescriptor specified,
I guess we need to inherit from the 'subClassOf' class.
Hi metze can you give us a example of such class.
Just define one, without specifying a defaultSecurityDescriptor.
any thought on the correct solution ?
I do not remember anything about inheriting a defaultSecurityDescriptor from the subClassOf in the docs - it is an attribute different from the nTSecurityDescriptor, and it is not required. I could not find it in the docs, but perhaps it has some default value which is used if it is not provided during object creation. I think we'd better experiment to see what happens an ask support for confirmation of the results.
P.S Also, in the algorithms for object creation, I do not remember looking for and using any defaultSecurityDescriptor other than that of the last structural class. But then, I did not test such a case as usually the defaultSecurityDescriptor is defined, maybe it just wasn't documented at the time.
Hm, I just found this:
"If the schema does not have a default DACL, the object's DACL is the default DACL from the primary or impersonation token of the creator."
Maybe this is the reason for the problem? I don't think we have implemented this...
No blocker for 4.1, schema updates are disabled by default
Any news on this one? Is it a blocker for 4.2?
Is this a showstopper for 4.2.0?
no regression, no blocker