[Date Prev][Date Next]
Re: SASL, slapd internal searches
On Sat, 8 Mar 2003, Kurt D. Zeilenga wrote:
> At 08:25 AM 3/8/2003, Igor Brezac wrote:
> >On Sat, 8 Mar 2003, Pierangelo Masarati wrote:
> >> > A little while back I committed some changes to the sasl/saslauthz code
> >> > to make sure that it enforced ACLs on all the internal searches it
> >> > performs. I think some of these changes are wrong/unnecessary. Really,
> >> > the point of an ACL is to control what an external user can see/touch.
> >> > When slapd is performing a search to map an authID to a DN, I think this
> >> > should be treated as a root-privileged operation, ignoring access
> >> > controls. Aside from the DN itself, nothing about the entry is ever
> >> > exposed to any external user. Comments?
> >> I did not study your changes; however, I think you should ensure
> >> that authz code does have the necessary auth permissions, such
> >> that an administrator is given the possibility to control how
> >> the auth/authz process takes place, and to inhibit some forms of
> >> it by means of ACL. I think this is the spirit of the auth
> >> permission level.
> >It is important that ACLs be applied to the resulting DN of the internal
> >search. However, saslauthz is more complicated than sasl-regex because
> >sasl-regex is setup by the administrator; on the other hand saslAuthz*
> >attribs are normally managed by users. If a root-privileged operations
> >are allowed, saslAuthzTo can easily be abused. I wonder if a special
> >saslAuthz acl can be implemented?
> The internal authentication/authorization searching, as with all
> other authentication/authorization access, should be done anonymously
> but require "auth" not "search"/"read". This allows the administrator
> have complete control over which values in the directory are to be
> used for authentication/authorization purposes.
Can you give me an ACL example which will prevent an authenticated
user from assigning rootdn or some other privileged dn to saslAuthzTo?