Bug 9279 - samdb didn't validate the validity of a SD before changing it
Summary: samdb didn't validate the validity of a SD before changing it
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.0.0rc2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on: 9278
Blocks:
  Show dependency tree / graph
 
Reported: 2012-10-10 07:48 UTC by Matthieu Patou
Modified: 2013-01-27 14:30 UTC (History)
1 user (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 Matthieu Patou 2012-10-10 07:48:10 UTC 
This is related to 9278, where the wrong value for sd_change control is passed to samdb with an ACL which only has DACL the last for bits are set to 0 so the samdb thinks that all the SD has to be changed which is not the case but could be an acceptable error if the db would reject any malformed SD.

To my understanding SD must have a owner, group, dacl and maybe sacl is optional.

In a nutshell we should check that the SD is valid if we are about to replace the whole SD.
Comment 1 Stefan Metzmacher 2012-11-12 08:39:12 UTC 
We validate the sd before writting it,
see SdFlagsDescriptorTests in source4/dsdb/tests/python/sec_descriptor.py.

It seems the bug #9278 is invalid.

Mattieu, do you still think we have a problem?
Comment 2 Matthieu Patou 2012-11-19 05:28:41 UTC 
Can't reproduce, the only problem I have now is that if you specify no owner and group in the attribute but specify flags with bits 0 & 1 set then user and group are set to some default value. I have to check how windows behave in this case.

In any case it seems not to be a blocker for 8622.