Bug 8638 - ACLs for structural classes without defaultSecurityDescriptor are broken
Summary: ACLs for structural classes without defaultSecurityDescriptor are broken
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: 4.3
Assignee: Andrew Bartlett
QA Contact: samba4-qa@samba.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-30 14:32 UTC by Stefan Metzmacher
Modified: 2014-11-27 14:53 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Metzmacher 2011-11-30 14:32:13 UTC 
If a class definition doesn't have a defaultSecurityDescriptor specified,
I guess we need to inherit from the 'subClassOf' class.
Comment 1 Matthieu Patou 2011-11-30 18:15:39 UTC 
Hi metze can you give us a example of such class.
Comment 2 Stefan Metzmacher 2011-12-23 15:01:16 UTC 
Just define one, without specifying a defaultSecurityDescriptor.
Comment 3 Matthieu Patou 2012-10-05 07:23:15 UTC 
Nadya,

any thought on the correct solution ?
Comment 4 Nadezhda Ivanova 2012-10-05 07:52:48 UTC 
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.
Comment 5 Nadezhda Ivanova 2012-10-05 07:57:18 UTC 
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.
Comment 6 Nadezhda Ivanova 2012-10-05 08:44:46 UTC 
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...
Comment 7 Stefan Metzmacher 2013-08-29 06:24:56 UTC 
No blocker for 4.1, schema updates are disabled by default
Comment 8 Karolin Seeger 2013-12-10 15:34:03 UTC 
Any news on this one? Is it a blocker for 4.2?
Comment 9 Karolin Seeger 2014-11-27 10:50:15 UTC 
Is this a showstopper for 4.2.0?
Comment 10 Björn Jacke 2014-11-27 14:53:39 UTC 
no regression, no blocker