[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SASL, slapd internal searches
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.
Kurt