[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problem in acl.c
Am Montag, 7. Mai 2001 20:38 schrieb Howard Chu:
> > -----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).
Or unless the proxy authenticates as a proxy with some more access.
> The question then is whether you should
> do (b) as well or not.
>
> 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.
This would also imply that the proxy has access to all these attributes on
the remote server (and the proxy can't just play man in the middle for
authentication purposes and authenticate as the user, that requires access).
I would guess it more efficient to grant the proxy read access to anything
that needs to be proxied and let the proxy get whole objects instead of
single attributes. (That might have some drawbacks for the operational
attributes, but I'm not sure which server should deliver this anyway, the
proxy or the remote server).
This does also mean, that the proxy needs to be secured like the remote
server, the proxies operator needs to be trusted and you need a way to
propagate the access controls and authentication information to the proxies.
(Doing this manual with ACLs on each single proxy seems a little error prone
to me). Maybe by the time all this stuff is working the ACIs are production
ready :-)
> 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.
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
>
> > At 02:20 PM 5/6/01, Pierangelo Masarati wrote:
> > >Kurt,
> > >
> > >I've a problem with the logics of acl matching when using back-ldap.
> > >It is not a big, big deal because it is triggered by very special
> > >conditions, however there it is.
> > >When checking for the subject clause "dnattr=<attr>", the <attr> is
> > >looked up in the entry, and its values are compared to the normalized
> > >value of the operation dn (see servers/slapd/acl.c line 685).
> > >This assumes that the ENTIRE entry is available
> > >when the comparison is made. However, when the back-ldap is used,
> > >only the portion of entry that was requested is currently available
> > >when processing the acl. Imagine I protected the "cn" of an entry
> > >with the clause "dnattr=member":
> > >
> > >access to dn="cn=my entry,dc=my,dc=domain" attr=cn
> > > by dnattr=member read
> > > by * none
> > >
> > >and the entry reads:
> > >
> > >dn: cn=my group,dc=my,dc=domain
> > >objectClass: top
> > >objectClass: groupOfNames
> > >cn: my group
> > >member: cn=my group,dc=my,dc=domain
> > >member: cn=someone else,dc=my,dc=domain
> > >
> > >while I'm performing the query:
> > >
> > >ldapsearch -D 'cn=someone else,dc=my,dc=domain' -w secret \
> > > -b 'cn=my group,dc=my,dc=domain' -s base cn
> > >dn: cn=my group,dc=my,dc=domain
> > >
> > >then the back-ldap asks the real DS only the "cn" attribute, and, at acl
> > >checking, it doesn't find the "member" attribute so the check fails,
> > >even if "someone else" has access to the "cn". In fact, if the member
> > >attribute is also required (or all the attrs are required), the acl
> > >succeedes:
> > >
> > >ldapsearch -D 'cn=someone else,dc=my,dc=domain' -w secret \
> > > -b 'cn=my group,dc=my,dc=domain' -s base cn member
> > >dn: cn=my group,dc=my,dc=domain
> > >cn: my group
> > >member: cn=my group,dc=my,dc=domain
> > >member: cn=someone else,dc=my,dc=domain
> > >
> > >In case the attr is not found in the entry, the entry should be read
> > >again with the <attr> of the "dnattr" explicitly required. Or, to
> > >avoid excessive overhead for other backends, this should happen in case
> > >the backend provides a method to reload the entry specifically
> > >requiring an attribute. I've noticed this is done by the method
> > >"backend_attribute", but I haven't been able to track the point where
> > >it is called (the acl stuff is really cumbersome!), and it is
> > >definitely NOT called in the case I discussed above.
> > >
> > >Any clues/ideas/suggestions?
> > >
> > >Pierangelo.
--
Stephan Siano Mail: Stephan.Siano@suse.de
SuSE Linux Solutions AG Phone: 06196 50951 31
Mergenthalerallee 45-47 Fax: 06196 409607
D-65760 Eschborn