[SCM] Samba Shared Repository - branch master updated - 3d0a3c1078d936a52ce82720ddc09b4037653655

Andrew Bartlett abartlet at samba.org
Tue Nov 18 02:08:30 GMT 2008


On Mon, 2008-11-17 at 07:42 -0500, simo wrote:
> On Sun, 2008-11-16 at 18:12 -0600, Andrew Bartlett wrote:
> > The branch, master has been updated
> >        via  3d0a3c1078d936a52ce82720ddc09b4037653655 (commit)
> >        via  16a3a2da78b1f2d5a1077e382a26466944f6c59e (commit)
> >        via  cf5c919c744c714b9be849e4d6424f7df92b328d (commit)
> >        via  5b796adb125174084cfc2a6f04cfdac5e9324ef8 (commit)
> >        via  00b63434063a128662d4ce83ce382fc2e6102d22 (commit)
> >        via  8e1934a3845944ba7d79848368976e82d182e8d1 (commit)
> >        via  109719de030cb2432bea991077b12b4cf937c108 (commit)
> >        via  9abd45979ee0415c16775f6dfd17a6e421091d5c (commit)
> >       from  1d9c88b3885728aba3d7fef85d80501125011f1c (commit)
> > 
> > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
> > 
> > 
> > - Log -----------------------------------------------------------------

> > commit 16a3a2da78b1f2d5a1077e382a26466944f6c59e
> > Author: Andrew Bartlett <abartlet at samba.org>
> > Date:   Thu Nov 13 14:07:29 2008 +1100
> > 
> >     Remove timeout event once we are calling the callback.
> >     
> >     (Even if the callback takes some time, this isn't a ldb_tdb timeout
> >     any more)
> >     
> >     Andrew Bartlett
> 
> I think this is wrong Andrew.
> The callback is fully part of the call and the timeout should apply.
> You may rise the timeout time if you think that normally we should give
> more time. But certainly not remove the timeout imo.

So who should remove the timeout?

With this in place, the timeout hangs around until talloc happens to
clean it up.  This means that an extra event gets propagated up the
callbacks, after the 'done' is processed, and quite possibly to use no
longer valid context pointers.  This is particularly important for an
operation that will take on other operations later. 

> > commit 109719de030cb2432bea991077b12b4cf937c108
> > Author: Andrew Bartlett <abartlet at samba.org>
> > Date:   Fri Nov 14 16:34:59 2008 +1100
> > 
> >     Remove restrictions on number of DN components in LDAP server
> >     
> >     There is no reason for these restrictions to be in the LDAP server -
> >     they belong in the LDB layer.  When accepting 'extended' or
> >     'alternate' DNs we can't tell anyway.
> 
> No, they certainly do not belong in LDB, as LDB does not have the same
> restrictions as the LDAP server. I would like you to put them back.

I strongly disagree, and in any case it is not possible once we accept
extended DN searches/modifies/deletes.  We already had to add hacks to
allow a modify of "" (required for schemaUpdateNow on the rootDSE).

At the time (Subject: 	Re: How to process schemaUpdateNow ldap request
Date: Tue, 01 Jul 2008 08:45:53 -0400) you said:

> Andrew Bartlett wrote:
> > If you look at ldap_server/ldap_backend.c, the macro VALID_DN_SYNTAX
> > takes two argument, the first being the DN, and the second is the
> number
> > of components it must have.  Set that to 0 and you should be right.
> > 
> > I don't see why this layer should be trying to determine if a DN is
> > valid (ldb can do that very well itself).  This looks like Simo's
> code,
> > according to 'git blame', so I'll flip-pass this question to him...
> 
> I think we added it before ldb was able to validate, then kept it for
> performance reasons, it make no sense to process the entry if it is
> going to be rejected.
> However a null DN should not be refuse I guess, feel free to patch the
> code to let that DN be considered valid (as it is).
> 
> Simo.

Given we must accept a NULL dn in these cases, I think we should accept
any syntactic valid DN, and let LDB figure out what is or is not a
possible DN, based on the actual content of the database. 

> >     Andrew Bartlett
> > 
> > commit 9abd45979ee0415c16775f6dfd17a6e421091d5c
> > Author: Andrew Bartlett <abartlet at samba.org>
> > Date:   Fri Nov 14 17:16:39 2008 +1100
> > 
> >     Always validate a DN when constructing from a string in python
> 
> This may make the python bindings much slower ... but perhaps that's ok
> for the bindings.

I think it is better to check there than later where we cannot catch the
error as easily.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20081118/fb783ac2/attachment.bin


More information about the samba-technical mailing list