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

Re: (ITS#5852) ACL behaviour does not match Admin Guide



On Mon, Dec 08, 2008 at 09:01:44PM +0000, quanah@zimbra.com wrote:

> > Full_Name: Andrew Findlay
> > Version: HEAD 2008-12-05
> > OS: SuSE 10.2
> > URL:
> > Submission from: (NULL) (88.97.25.132)
> >
> >
> > Section 7.2.5 Access Control Examples says:
> > ...
> > Also note that if no access to directive matches or no by <who> clause,
> > access is denied. That is, every access to directive ends with an
> > implicit by * none clause and every access list ends with an implicit
> > access to * by * none directive.
> >
> > The statement about access *lists* ending with a deny directive is wrong
> > (or at least misleading).
> 
> I think it is quite clear:
> 
>        The structure of the access control directives is
> ...
>      Lists of access directives are evaluated in the order  they  appear  in
>        slapd.conf.
> 
> 	Each <who> clause list is implicitly terminated by a
> 
> 	    by * none stop
> 
> 
> So, there are acl directives where each directive is an element of a list. 
> Every element of a list of acl directives is terminated by * none stop.

That is not the aspect that worries me here. The statement in 7.2.5
agrees with what you say about individual directives.

I am concerned about the behaviour of complete access *lists*.
For example, if my global acccess list says:

	access to * by * read

and the access list for a BDB database holding the suffix 'dc=example,dc=org'
says:

	access to dn.exact="cn=nonesuch,dc=example,dc=org" by users read

(i.e. it is very restrictive and does not give ANON anything)

In this case the statement in 7.2.5 implies that ANON should not be able
to read dc=example,dc=org but tests show that it can. Changing the global
access list to:

	access to * by users read

prevents ANON from reading dc=example,dc=org and thus proves that the
per-database access list does not end with 'by * none stop' (but the
complete list including the global section does).

Sections 7.2.4 and 7.3.4 describe this behaviour rather better, but
do not mention the default-deny that gets appended to a non-empty
access list.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------