s4/ldb:introduce the LDB_CONTROL_PROVISION_OID control

[Andrew Bartlett]

On Sat, 2010-10-23 at 18:41 +0200, Matthias Dieter Wallnöfer wrote:
> The branch, master has been updated
>        via  c7d7c8f ldb:ldb.h - include a comment that the relax control is mainly used by the OpenLDAP backend
>        via  f9a6ff4 s4/ldb:introduce the LDB_CONTROL_PROVISION_OID control
>        via  89c42a9 ldb:rename LDB_CONTROL_BYPASSOPERATIONAL_OID into LDB_CONTROL_BYPASS_OPERATIONAL_OID
>        via  a60965b s4:dns_server - fix counter types
>        via  ee913f4 tdb: commit the version 1.2.7 signatures
>       from  72c8ccd s4 dns: Implement update record prescan logic
> 
> http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master

> commit f9a6ff482c8d03e7e46fd6925d58214b7a097e02
> Author: Matthias Dieter Wallnöfer <mdw at samba.org>
> Date:   Sat Oct 23 16:15:51 2010 +0200
> 
>     s4/ldb:introduce the LDB_CONTROL_PROVISION_OID control
>     
>     This control is exactly thought for the actions which previously were performed
>     using the RELAX one.
>     
>     We agreed that the RELAX control will only remain for interactions with OpenLDAP.

Thanks for doing this. 

In terms of the security issue, we have already solved that (but I
forgot to close the bug), by ensuring that only controls that are
registered with our rootDSE module may be accepted over untrusted
channels (we now have code to mark requests as untrusted for this
purpose).

The next step here is to separate the different purposes of relax, into
things like PROVISION, repl_meta_data or perhaps even finer grain like
'specify GUID' (as values in the control, potentially renamed).  We also
need to ensure that we still map the uses that must make it to OpenLDAP
down to that layer as relax. 

The goal I have here is to have the caller specify more closely what
exact relaxation of the rules it wants, so that we don't accidentally
violate *other* rules in doing so.

Please don't do a global replace to 'finish' the conversion here -
please show me the patches.  I would like to see them before they go in,
as this area, particularly as it interacts with OL, is subtle in
places. 

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/20101024/323e68b7/attachment.pgp>