s4: problems with DSDB_TRU

[Andrew Bartlett]

On Thu, 2011-02-03 at 11:27 +0200, Nadezhda Ivanova wrote:
> If that is the idea, shouldn't we have something like:
> if (dsdb_flags & DSDB_FLAG_TRUSTED || !
> ldb_req_is_untrusted(parent_req)) {
> ldb_req_mark_trusted(req);
> }
> in the dsdb functions?
> Perhaps it's there but I don't see it, checking how trusted the parent
> request is.

This is done in the ldb_build_search_request_ex and similar functions,
based on the now passed parent parameter. 
		req->handle->flags = parent->handle->flags;


> In any case, we do have internal requests that should be trusted even
> if the parent is not, for example - the objectclass module needs to
> make a search in the schema partition to check if the object class
> provided by an add operation is valid. The user may not have rights to
> read that, but have the rights to create a new object with the
> specified object class.

Then this is a case where it is reasonable to mark a request as trusted.
But we need to soon determine what 'trusted' and 'untrusted' really
means.  Currently it tries to convey the source of the original LDB
request - firstly to strip controls, secondly to refuse anonymous
operations in rootdse, and thirdly to assist in the 'not permitted to
modify over LDAP' rules for LSA objects.  

It is of course reasonable to have modules generate trusted operations
from such inputs, but we need to be careful about what extra privileges
a 'trusted' operation should have, and what things really need to be
trusted.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.