Blocking anonymous LDAP operations and interaction with dsHeuristics

[Andrew Bartlett]

On Thu, 2010-11-25 at 13:10 +0200, Nadezhda Ivanova wrote:
> Hi Andrew,
> Sorry, wrong wording on my part, what I meant is that initially in the
> process of implementation I added this code to rootDSE, but moved it in
> acl_read later. Logically this seems like access list functionality, with
> the dsHeuristics flag controlling whether the SD permissions are being taken
> into account for anonymous or we always deny access. Whether to allow or
> deny an action based on the security token is an access module
> functionality. I also do not see the problem with the acl_read module being
> that one clear spot that this is done. 

Except that you are missing one important point:  This isn't just about
reads!  This needs to be about every LDAP operation, reads, writes,
extended operations etc. 

Currently (for better or worse) rootDSE blocks the use of unregistered
LDAP operations, and using rootDSE allows us not to allow security
bypass for @ records (even if LDAP clients are currently technically
unable to read them, I feel a bit happier without the exception). 

> I guess there is no technical reason
> not to put it in rootDSE, I just believe that logically it does not belong
> there. If you feel strongly it should be there, I suppose I can live with
> that.
> 
> As for polling dsHeuristics - the tests in acl.py did pass against windows
> when I wrote them, so I guess it is expected to poll it every time or
> synchronize LDB in some way. If we decide to not support this behavior, we
> have to rewrite them in a way that will not compromise the actual tests, e.g
> re-establishing the connection after we modify dsHeuristics. You can push
> your patch and I can fix the tests later, they are in knownfail anyway, but
> is it correct to modify the tests to match a behavior rather than the
> opposite? This will just hide a difference of behavior and goes against the
> idea of interoperability...

I see you just changed the tests.  Thanks!

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101126/78b57089/attachment.pgp>