Setting 'nTSecurityDescriptor' via LDAP fails

[Nadezhda Ivanova]

Hi Simo,
Could you elaborate a bit? Where do we set the handler? The problem concerns the Ldb python class that is used in tests and provisioning and is in the C code of the binding. At that particular place (puldb.c:1276), the data type is not checked, only if we check for single or multi-valued attribute...

Nadya

-----Original Message-----
From: simo [mailto:idra at samba.org] 
Sent: Tuesday, March 17, 2009 3:55 PM
To: Zahari Zahariev
Cc: 'samba-technical at lists.samba.org'; Andrew Bartlett
Subject: Re: Setting 'nTSecurityDescriptor' via LDAP fails

On Tue, 2009-03-17 at 13:17 +0200, Zahari Z. wrote:
> Andrew Bartlett wrote:
> > On Tue, 2009-03-10 at 14:34 +0100, Stefan (metze) Metzmacher wrote:
> >   
> >> Zahari Z. schrieb:
> >>     
> >>> Andrew Bartlett wrote:
> >>>       
> >>>> On Fri, 2009-03-06 at 15:11 +0200, Zahari Z. wrote:
> >>>>  
> >>>>         
> >>>>> Hello Andrew and Samba4,
> >>>>>
> >>>>> I am raising this issue again. This is about sending ndr_packed()
> >>>>> nTsecurityDescriptor object via LDAP connection.
> >>>>>     
> >>>>>           
> >>>>  
> >>>>         
> >>>>> Hope the explanation is clear and you would be able to help us
> >>>>> overcome this LDAP situation.
> >>>>>     
> >>>>>           
> >>>> Does this test pass against Windows 2003 or 2008?
> >>>>
> >>>> Andrew Bartlett
> >>>>
> >>>>   
> >>>>         
> >>> Hello Andrew,
> >>>
> >>> It does not pass against Windows2003. It crushes with 'Constrain error'
> >>> that resolves according to winerror.h this error sesolves to 'Invalid
> >>> nTSecurityDescriptor'.
> >>>
> >>> See the error against Win2003:
> >>>
> >>> Traceback (most recent call last):
> >>>  File "./lib/ldb/tests/python/acl-test.py", line 100, in test_acl_read
> >>>    "ntSecurityDescriptor" : ndr_pack(x),
> >>> LdbError: (19, 'LDAP error 19 LDAP_CONSTRAINT_VIOLATION -  <0000053A:
> >>> AtrErr: DSID-03150B5E, #1:\n\t0: 0000053A: DSID-03150B5E, problem 1005
> >>> (CONSTRAINT_ATT_TYPE), data 0, Att 20119 (nTSecurityDescriptor)\n> <>')
> >>>
> >>> My guess is that something happens at the moment of writing to database
> >>> or while sending.
> >>>       
> >> I think you need to use the a control:
> >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ldap/ldap/ldap_server_sd_flags_oid.asp
> >>     
> >
> > Once this is fixed, I think the issue may be due to different formats of
> > the attribute (samba translates between text and binary).  Try printing
> > the original value obtained over LDAP to see how it differs before you
> > try parsing.
> >
> > Andrew Bartlett
> >
> >   
> Hello Samba4,
> 
> We want to announce  :)   that we have successfully debugged and fixed 
> the problem with ndr_pack(nTSecutityDescriptor) sending via LDAP using 
> Samba4 ldb.add().
> 
> (1) What the problem really was?
>  
> The issue was that sending binary data using ldb.add() did not work. The 
> issue was not raised before now as most of the properties that are set 
> by ldb.add() are plain strings.We, however, tried using it to set 
> ntSecurityDescriptor in binary format. In file 
> source4/lib/ldb/pyldb.c:1276, function PyObject_AsMessageElement() where 
> data from python objects is converter into am ldb_message, 
> talloc_strndup is used to copy/duplicate data. When we tried to send 
> binary data (nTSecurityDescriptor) it did not work
> because there was a null character '\0' e.g. "bla\0foo". When 
> talloc_strndup() reaches a null character it stops copying and data is 
> transmitted with wrong value but correct size. Having wrong value 
> transmitted through LDAP, Win2003 immediately throws "Constraint 
> violation" due to data inconsistency.
> 
> (2) How did we end up fixing the problem?
> 
> What fixed the problem and did not raise more issues is: substitute 
> talloc_strndup() with talloc_memdup(), allocate 1 more character and put 
> null character ('\0') in the extra place so data copied is null terminated.
> 
> (3) What happens when we just changed talloc_strndup() to talloc_memdup()?
> 
> This is what we first tried. Unfortunately after double checking with 
> "make test" we saw more errors were generated. The most obvious issue 
> was source4/setup/newuser script was crashing with LDAP error because of 
> data inconsistency. More characters were copied after talloc_memdup() 
> than stated by its size. Got back to debugging and came to the 
> conclusion that successive data handling is based on that data is null 
> terminated string and strlen() defines the final length of the value not 
> the real size passed along. After null terminating processed data came 
> out of memdup() everything seems to be OK. Our concern is that null 
> terminating works around a bigger problem with data size handling 
> somewhere in the ldb library - size is being calculated with strlen() 
> instead of using the value[].length field.


Zahari are you setting the ldb handler for nTSecurityDescriptor to be
LDB_SYNTAX_OCTET_STRING ?

If not that's the first step. If that fails then we need to check what's
going on.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>