Re: Attribute scope of attr=entry in an ACL

[Ace Suares <ace@suares.nl>]

> Hello all,
>
> I have OpenLDAP 2.1.16.
>
> Like many, I have a question about ACLs. Does the "attr=entry" include
> all of the attributes in the entry itself? It would seem not. I have
> ACLs that read thus:
>
> (above is an ACL that limits access to attr=userPassowrd)
> access to dn="cn=([^,]+),ou=([^,]+),ou=([^,]+),o=people,o=company"
> attr=children
>         by self write
>         by dn="cn=$1,ou=$2,ou=$3,o=people,o=company" write

I think the 'by self write' is superfluous, but it should'nt matter. 

>         by group="cn=Admin,o=company" write
>         by group="cn=Admin,o=people,o=company" write
>         by group="cn=Admin,ou=$3,o=people,o=company" write
>         by group="cn=Admin,ou=$2,ou=$3,o=people,o=company" write

For testing, remove all the admins !

> access to dn="cn=([^,]+),ou=([^,]+),ou=([^,]+),o=people,o=company"
> attr=entry
>         by self write

people login als cn=([^,]+),ou=([^,]+),ou=([^,]+),o=people,o=company,
you say. that means 'by self write' should give write access to this, and 
by users read should give read access to this, if you are not logged in as 
this entry.

Remove all the admins for testing !

To me, it looks very good. It looks very much like my own rules, i.e. it has 
the same structure. It *should* would, I think. i can't find a logical flaw.

It may be noted that other users than 'self' can NOT read child-entries.
Also, you are saying nothing about anything above 
cn=([^,]+),ou=([^,]+),ou=([^,]+),o=people,o=company !

>         by group="cn=Admin,o=company" write
>         by group="cn=Admin,o=people,o=company" write
>         by group="cn=Admin,ou=$3,o=people,o=company" write
>         by group="cn=Admin,ou=$2,ou=$3,o=people,o=company" write
>         by users read
>         by * auth
> .....
>
> No anonymous access (except auth or compare on userPassword) is
> allowed. Everyone authenticates with their DN
> (cn=Person*,ou=region*,ou=org*,o=people,o=company). Everyone needs read
> only access to the address books above their entry and write access to
> their address book entries below their entry. Users should have read

in these rules, you are not giving any access to 'the address books above 
their entry' !

> access to the cn=Person*,ou=region*,ou=org*,o=people,o=company entries
> and above, but not to anything below that point. Administration is done
> via the groupOfNames objectClass (each level of company, people, org*
> and region* has an administration group).
>
> I do an ldapsearch on '(objectclass=*)' with a base of
> 'o=people,o=company'. With "attr=entry" at the end of that second ACL,
> and starting slapd with -d -1, I see that the ACL matches, but on the
> attribute check, no joy. When I remove "attr=entry", the ACL matches and
> all entries below are displayed.

what is the suffix in your slapd.conf ?

since you are giving a base that is 'higher' than the access rules you have, 
it should be IMPOSSIBLE to travel 'down the tree. (At least, that's what I 
understand of it.)
So, by lack of any access to  'o=people,o=company', the logged in DN can not 
see what's under there.

However, removing or adding the 'attr=entry' should not have to make any 
difference. Certainly, it should not display the whole tree, since you have a 
preceding (earlier evaluated) rule that arranges access to children !

Actually, also you ar enot giving any access to the RootDSE. I am still 
wondering if that makes any difference.

Shortly said, I don't know what's wrong. I have similar problems (illogical 
effect of ACL's) in 2.0.27

I tested with a very very simple ACL. Maybe that's good for you too. Just make 
up ONE ACL that's very very simple and that restrcits access to the first 
level. Then add rules and see what changes. And tell us ! (Especially if you 
solved it !)

TIA
Ace








>
> Either way (with and without attr=entry), the user can not write
> entries below the entry the user authenticated as.
>
> My directory structure is thus:
> o=company
>
>  |--o=people
>  |
>  |    |--ou=org1
>  |    |
>  |    |    |--ou=region1
>  |    |    |
>  |    |    |    |--cn=Person1
>  |    |    |    |
>  |    |    |    |    |--cn=Personal Address Book Entry1
>  |    |    |    |    |--cn=Personal Address Book Entry2
>  |    |    |    |    |--...
>  |    |    |    |
>  |    |    |    |--cn=Person2
>  |    |    |    |
>  |    |    |    |    |--cn=Personal Address Book Entry1
>  |    |    |    |    |--cn=Personal Address Book Entry2
>  |    |    |    |    |--...
>  |    |    |    |
>  |    |    |    |--...
>  |    |    |    |
>  |    |    |    |--cn=Address Book
>  |    |    |    |
>  |    |    |    |    |--cn=Region1 Address Book Entry1
>  |    |    |    |    |--cn=Region1 Address Book Entry2
>  |    |    |    |    |--...
>  |    |    |
>  |    |    |--ou=region2
>  |    |    |
>  |    |    |    |--...Sub-structure = region1
>  |    |    |
>  |    |    |--...Other regions with their sub-structure = region1.
>  |    |    |
>  |    |    |--cn=Address Book
>  |    |    |
>  |    |    |    |--cn=Org1 Address Book Entry1
>  |    |    |    |--cn=Org1 Address Book Entry2
>  |    |    |    |--...
>  |    |
>  |    |--ou=org2
>  |    |
>  |    |    |--Sub-structure pretty much the same as above.
>  |    |
>  |    |--...Other orgs with their sub-structure = org1
>  |    |
>  |    |--cn=Address Book
>  |    |
>  |    |    |--cn=Company Address Book Entry1
>  |    |    |--cn=Company Address Book Entry2
>  |    |    |--...