[PATCH] Failure to modify nTSecurityDescriptor attribute
abartlet at samba.org
Tue Jun 30 17:05:24 MDT 2009
On Wed, 2009-07-01 at 01:00 +0200, Jelmer Vernooij wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Andrew Bartlett wrote:
> > On Tue, 2009-06-30 at 20:04 +0200, Jelmer Vernooij wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> Hi Zahari,
> >> Zahari Zahariev wrote:
> >>> Method ldb.modify_ldif() does not work at all if you try to use
> >>> it for nTSecurityDescriptor modification.
> >>> The patch below implements a simple unittest for this behavior.
> >>> First step is to create a regular user then save its
> >>> nTSecurityDescriptor in SDDL format. Next we create a
> >>> "samba.security.descriptor" python object which is ndr_packed()
> >>> and included in ldb.modify_ldif() request changing our
> >>> previously created user's descriptor. After this we look up the
> >>> same user nTSecurityDescriptor then transform it into SDDL
> >>> format and assertNotEqual() both this and the initial value. If
> >>> ldb.modify_ldif() operation is successful then the the two
> >>> SDDL representations must be different but as this
> >>> functionality fails in our case they are the same!
> >>> Another interesting observation is that ldb.modify_ldif() fails
> >>> to change a security descriptor attribute with absolutely no
> >>> warning or error in other words if you do not look it up
> >>> afterwards you would have no clue that this operation fails.
> >> Have you tried modifying any other attributes than
> >> nTSecurityDescriptor? Does that work ok? If it's specific to
> >> nTSecurityDescriptor, it's probably a bug in the LDB module that
> >> handles it. If it's a problem everywhere, it's more probably a
> >> bug in ldb.modify().
> > Jelmer,
> > The difference with nTSecurityDescriptor is that we use the LDIF
> > read/write functions for it. This would make it different to any
> > other binary attribute.
> In that case, shouldn't we be returning an error if the attribute
> isn't formatted correctly rather than silently ignoring it?
I didn't claim there are not bugs, but just wanted to point you at a
spot to look :-)
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090701/607a73f8/attachment.bin
More information about the samba-technical