[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem in acl.c

Howard Chu wrote:

> > -----Original Message-----
> > From: owner-openldap-devel@OpenLDAP.org
> > [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> > ACL's and proxies are fun.  I think one needs to choose:
> >         a) remote server enforces access controls
> >         b) proxy enforces access controls
> >
> > In either case, what the proxy returns to the client must
> > be consistent with RFC 2251:
> >    Servers which perform caching or shadowing MUST ensure that they do
> >    not violate any access control constraints placed on the data by the
> >    originating server.
> >
> > Kurt
> At a guess, the remote server does whatever it does, regardless of who
> calls it. That means (a) is always true (unless the remote server has
> explicitly turned controls off). The question then is whether you should
> do (b) as well or not.

I guess in case (b) ACLs can only be more restrictive than in (a);
there is no way that the opposite can occur.

> If you want to handle all of these cases of missing attributes, I
> suggest that back-ldap should walk through the backend-specific ACLs
> looking for all referenced attrs and add them to the attribute list
> before passing on the search.

Well, although technically this might be an efficient solution, in this
case you'd be altering the nature of the request you're proxying.
I'd prefer to alter it as little as I can.

> Realize though that you're out of luck in evaluating ACLs on modify
> operations, unless you are going to do a fetch first. I suppose you could
> take the position that one would never modify an entry that one hasn't
> looked at recently, and try caching search results.

Or better, the ACL chacking code should be able to do an extra
lookup (possibly bound as an administrative person) in order
to check permissions, as it is currently done in back-ldap/group.c;
the performance penalty would occur only in writing if the approach
you suggested above is adopted.

Notice that in this case the results of the extra search cannot ever
be returned or disclosed in any manner, because the search with
administrative privileges is never returned. Only the presence of
an entry that matches the search filter is returned as a success/failure

Maybe an even cleaner way to do this would be a compare
(but a compare for the objectClass and one for the member
would be required) ...


Dr. Pierangelo Masarati    mailto:ando@sys-net.it
Developer, SysNet s.n.c.   http://www.sys-net.it