s4: problems with DSDB_TRU

Nadezhda Ivanova nivanova at samba.org
Thu Feb 3 02:48:01 MST 2011

Ok, I suppose I understand now, I will take a better look and remove setting
of the flag if it is not necessary for the reasons specified, and send the
patch for review. The only thing that worries me is having all of the tests
work with administrative privileges that would mask if we are missing
something. I will have to think about additional tests with non-admin users.

On Thu, Feb 3, 2011 at 11:36 AM, Andrew Bartlett <abartlet at samba.org> wrote:

> 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/<http://samba.org/%7Eabartlet/>
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.

More information about the samba-technical mailing list