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

Re: An ACL question

Rob Tanner writes:
> I understand the general rule for ordering ACLs, but the application
> still sometimes throws me.

See man slapd.access, section OPERATION REQUIREMENTS, search operation.

You do not grant anonymous search and read access to anything.  You
can't read the attributes if you can't find and read the entries.

(Untested response, beware:-)

> In my people hierarchy, I need several attributes to be visible to
> anonymous connections: uid and mail.  Here's my original set of ACLs:
> access to dn.one="ou=people,o=linfield.edu"
>   attrs=userpassword
>     by anonymous auth

      by self =wx

(=w is safer than 'write' - people normally do not need access to read
or search for passwords.)

access to dn.one="ou=people,o=linfield.edu"
     by * read

or (if you for some reason want to exclude other users even though they
can read if the bind anonymously)
     by dn="cn=Postfix,ou=Special Users,o=linfield.edu" read
     by group/linfieldGroupOfUniqueNames/uniqueMember="cn=ferpaadministrators,ou=People,o=linfield.edu" read
     by self read
     by anonymous read

plus you need 'search' or better access to the attributes in the search
operation's filter.

> access to dn.one="ou=people,o=linfield.edu"
>     by dn="cn=Postfix,ou=Special Users,o=linfield.edu" read
>     by group/linfieldGroupOfUniqueNames/uniqueMember="cn=ferpa
> administrators,ou=People,o=linfield.edu" read
>     by self read
> access to dn.one="ou=people,o=linfield.edu"
>   attrs=userPassword,maillocaladdress,useDefaultAlias,spamDisposition,checkForDirtyWords
>     by self write

This one is never used because the previous 'to' clause is more general.
So swap these two access statements.  Also the userPassword access is
never used since you already handled that above - which is why I added
write access there.

Finally you need anonymous search access to "ou=people,o=linfield.edu",
but the default 'access to * by * read' handles that (unless you
override it).