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

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



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


With slapd(8) you mean the file in the distribution under doc/man8/slapd.8 ?
In both version 2.0.27 and 2.1.12 I could not find any reference to ACL's.

In 2.1.12 in doc/man5/slapd.access.5 is some information, the same as in the 
ldap admin guide 2.1 as far as I can see. It's not clear to me where the 
'system' entries are listed and that there are system entires at all and how 
to put ACL's on them.
>
>
> By STATS, I was referring to the log level which provides basic
> information about protocol requests and responses.

In slapd.conf.5 (version 2.1.12) I could only find the following entries for 
logging:

                      1      trace function calls
                      2      debug packet handling
                      4      heavy trace debugging
                      8      connection management
                      16     print out packets sent and received
                      32     search filter processing
                      64     configuration file processing
                      128    access control list processing
                      256    stats log connections/operations/results
                      512    stats log entries sent
                      1024   print communication with shell backends
                      2048   entry parsing


Which one do you refer to as STAT ? (256 or 512 ?)

> >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.

In the openldap admin guide 2.1, the phrase 'root DSE' appears exactly once, 
and not in an explanatory context. The acronym 'DSE' appears 3 times. 
(including the above phrase). 

Until now I assumed that the root DSE the top entry is in the database, in my 
case: app=qwido. Is that right ?

>
> Please feel free to submit documentation updates.

I will, once I know what I am doing ;-0

I had collected a lot of info on ACL's before, but 'jsanchez' beat me in 
putting it in the Faq-o-matic.

> >Feb 23 18:13:16 curacao slapd[1057]: => acl_get: [1] check attr
> > objectClass
{snip}
> >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.

So, the 'thing being matched' is 'attr objectClass' and it is matched against 
the first ACL in the list ?

{snip}
> >But, what's the nsub: 1 doing ?

> number of substitutions.

Thanks.

{snip}
> >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.

So, even if I say 'defaultaccess=write' but have at least 1 access rule (ACL) 
specified, then the defaultaccess will be ignored, even if nothing matches 
that rule !? (I had a totally different idea of what defautlaccess meant !)

rule a:

> >access to attr=userpassword
> >        by self write
> >        by group="group=managers,app=qwido" write
> >        by anonymous auth
> >
{snip}
> Rule a actually says: "allow self and managers to modify
> userPassword; allow anonymous to authentication"

by 'modify' you mean 'add (if it's not there), delete (if it's there) or 
change (if it's there)' (assuming that the schema allows it) ??

This question comes around to my misconception about the 'write' privilige - 
in many cases 'write' means not only modify (change) but also add and delete.

rule b:
> >access to dn="app=qwido"
> >        by dn="app=qwido" read

{snip}
>
> 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

I assume it is equally equivalent to
         access to dn="app=qwido" by self read

or... not ?


> 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

Your answer saves me from going crazy. There must be something severely wrong 
in my setup. Because, I can view the entire tree ! (while binding as 
app=qwido)

> >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

I don't know. I thought I hadn't. I checked everything a hundred times. Maybe 
I oversee something. I have send you (off-list) the ldap config and database 
(and the little installer i use to test this).
Maybe you can find what's wrong. 

But at least I now know that the way it works in my situation, is *not* the 
way it is supposed to work, and that makes me feel a hell of a lot better.

Thanks,
Ace