Re: [LDAP-SOFTWARE] ACLand regex (matching self)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:33 AM 2/23/2003, Ace Suares wrote:
>> Well, you might want to find them.  Aside from allowing you to
>> test the software, the suite provides a number of useful examples.
>
>Thank You. I have downloaded 2.0.27 from openldap.org and untarred it.
>The test scripts didn't work of ocurse, since I haven't compiled openldap yet, 
>I am just browsing the files. The first thing I find in tests/data is a file 
>called slapd-acl.conf. An extract:
>
># normal installations should protect root dse,
># cn=monitor, cn=schema, and cn=config
>
>>From this, I gather that there is such thing as 'protecting' the schema.
>If this is correct, that could explain some of my troubles with GQ (Which 
>would render that topic off-(off-topic) ).

slapd(8) allows one to place access controls on any and all entries
including system entries.

>> confused as to what the applicable subject (authorization) and
>> target (entry) DNs are.  The logs tell exactly which who is
>> accessing what (STATS) and "to" and "by" clauses contribute to
>> the access allowed/denied (ACLs).  Other logging may also be useful.
>
>In my log file, which is with loglevel 128, I can not find any string 'STATS' 
>even with grep -i.

By STATS, I was referring to the log level which provides basic
information about protocol requests and responses.

>Just an extract from my logfile.
>
>Feb 23 18:13:16 curacao slapd[1057]: => access_allowed: search access to "" 
>"objectClass" requested
>
>I explain this as: the function 'access_allowed' tries to find out if 'search 
>access to "" "objectClass" ' is  available.
>
>Immediately I ask my self: what is this "" between to and "Objectcllas" ?

The first string is the target DN, the second string is the target attribute.
A DN of "" implies the root DSE is the target.

>And then, I am lost. Can't find it in the docs.  (You *know* I am willing to 
>spend hundreds of hours wriing the docs, by lack of other possibility to 
>contribute to the source code itself...!).

Please feel free to submit documentation updates.

>Feb 23 18:13:16 curacao slapd[1057]: => acl_get: [1] check attr objectClass
>
>Next line: the function 'get_acl' (GET ACL ?) checks for any ACL's matching 
>objectClass
>But, what's that [1] doing there ? 

[1] means slapd is looking at the 1st access statement in the list,
checking if the target attribute matches.

>Feb 23 18:13:16 curacao slapd[1057]: => dnpat: [2] oc=(.*),app=qwido nsub: 1

Now slapd has moved on to the second.


>It found a dnpat (DN Pattern ?) that is: oc=(.*),app=qwido
>But, what's the nsub: 1 doing ? 

number of substitutions.

>Feb 23 18:13:16 curacao slapd[1057]: => dnpat: [3] app=qwido nsub: 0

Its now moved onto the 3rd directive.

>Feb 23 18:13:16 curacao slapd[1057]: => dnpat: [4] app=qwido nsub: 0

And the 4th.

>two times the same dnpat, probably the same pattern in different ACL's ? 

I would assume so.

>Could  be ! what's the nsub: 0 ?

No substitutions.


>Feb 23 18:13:16 curacao slapd[1057]: <= acl_get: done.
>
>it's done

>Feb 23 18:13:16 curacao slapd[1057]: => access_allowed: no more rules
>
>there are no more rules
>Feb 23 18:13:16 curacao slapd[1057]: => access_allowed: search access denied 
>by =n
>
>acces denied (by default, because there was no rule that matched, and 
>defaultaccess=none.... ?)

If none of teh specified rules are applicable, then access is
always denied.   defaultaccess is only considered with there
are no rules specified.

>The simplest ACL I can devise is this:
>
># protect all userPasswords.
># qwido: managers have access to all passwords
>access to attr=userpassword
>        by self write
>        by group="group=managers,app=qwido" write
>        by anonymous auth
>
>access to dn="app=qwido" 
>        by dn="app=qwido" read
>        
>
>I expect it to do the following:
>
>a. let every entry authenticate itself against it's password. If an 
>'anonymous' bind is done, it should authenticate. If an existing DN is 
>binding, it should authenticate because of 'by self write'
>Forget about that group, for now, but it should be able to authenticate too.

Rule a actually says: "allow self and managers to modify
userPassword; allow anonymous to authentication"

>b. Let the one that binds to the database as 'app=qwido' (yes, that entry has 
>it's own userpassword) read the entry app=qwido and anything under it.

Rule b actually says: "allow app=qwido to read app=qwido".  It
is equivalent to saying:
        access to dn.exact="app=qwido" by self read

It says nothing about DNs under "app=qwido".  For this, you'd
need to say:
        access to dn.subtree="app=qwido" by dn="app=qwido" read

>BUT
>when binding as, for example, 'oc=isp001,app=qwido' which is an existing entry 
>and has it's own userpassword, I can still read the entire tree.

Then I suspect you have other access control statements.

Kurt