--On Friday, January 30, 2009 4:42 PM -0800 Tim Gustafson tjg@soe.ucsc.edu wrote:

Hi,

I have the following in my slapd.conf:

access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read

However, anyone (even unbound anonymous users) can access cn=log without any problems. I don't want anyone but ldap-admins to be able to access this subtree.

I'm thinking that I must be missing something really simple here. Am I doing something wrong? Any help is greatly appreciated.

What are your other acls? ACLs are applied as they are reached, so if a previous ACL allows access to cn=log, this one will never get evaluated.

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Tim Gustafson a écrit :

This is the first ACL in the file.

Tim Gustafson SOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354

-----Original Message----- From: Quanah Gibson-Mount quanah@zimbra.com

Date: Fri, 30 Jan 2009 17:24:47 To: Tim Gustafsontjg@soe.ucsc.edu; openldap-software@openldap.org Subject: Re: ACL Question

--On Friday, January 30, 2009 4:42 PM -0800 Tim Gustafson tjg@soe.ucsc.edu wrote:

...

Hi,

I have the following in my slapd.conf:

access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read

However, anyone (even unbound anonymous users) can access cn=log without any problems. I don't want anyone but ldap-admins to be able to access this subtree.

I'm thinking that I must be missing something really simple here. Am I doing something wrong? Any help is greatly appreciated.

What are your other acls? ACLs are applied as they are reached, so if a previous ACL allows access to cn=log, this one will never get evaluated.

Similarly, other ACLs after this one may grant access to cn=log.

Your current ACL only grants read access to the group ldap-admins. It doesn't specify rights for other users. Explicitly deny access to others like this:

access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read by * none

Jonathan

Tim Gustafson wrote:

...

Similarly, other ACLs after this one may grant access to cn=log. Your current ACL only grants read access to the group ldap-admins. It doesn't specify rights for other users. Explicitly deny access to others like this

I tried that as well and got the same result. Also, the man page says that each "access to" stanza is implicitly terminated by a "by * none", so specifying this seems to be unnecessary.

Absolutely. My bad.

A few things you could check here: 1) If this ACL is in the global context, per-database ACLs will precede it. They may be giving read access. 2) Run with loglevel ACL. The log will detail ACL evaluation, and you'll see exactly which ACL grants access.

Jonathan