[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [LDAP-SOFTWARE] ACLand regex (matching self)
> 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) ).
Anyway, I havent read any information on this in the slapd admininistrators
guide, neither in 2.1 or 2.0, or I overlooked it.
> >But, I was not pointing out that the self directive doesn't work, I just
> >pointed out that the self directive didn't work in this special
> > circumstance.
>
> I assume you mean "didn't work as expected". I suspect you are
Exactly. But the problem is that I really don't know what to expect.
I have read the admin guides 2.0 and 2.1, but have no clue as how the ACL's
shoudl work.
I have been working with openldap since 1.3 or so, and run qmail-ldap with it
quite nicely, but the ACL's have alwasy been 'misintepreted' by me (since the
software is not at fault... (grin)).
My only solution was to 'open up' and then 'open up wider' but since
everything is hapening local, I don't bother too much.
This time I want to tighten access to certain objects down, at the
ldap/database level and not only at the application level (some PHP script).
For at *least* 16 hours now, and even more hours a while ago (just before the
ACL's appeard in the FAQ-U-Matic) I've been banging away at these ACL's.
I can *not* get my mind around it.
>From the documentation I read, I think I should be able to devise a strategy.
However *every* time when I test my 'cunning plan', it turns out to be
something completely different.
> 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.
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" ?
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...!).
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 ?
Feb 23 18:13:16 curacao slapd[1057]: => dnpat: [2] oc=(.*),app=qwido nsub: 1
It found a dnpat (DN Pattern ?) that is: oc=(.*),app=qwido
But, what's the nsub: 1 doing ?
Feb 23 18:13:16 curacao slapd[1057]: => dnpat: [3] app=qwido nsub: 0
Feb 23 18:13:16 curacao slapd[1057]: => dnpat: [4] app=qwido nsub: 0
two times the same dnpat, probably the same pattern in different ACL's ? Could
be ! what's the nsub: 0 ?
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.... ?)
As you see, I am in the dark. I would feel very stupid if there is splendid
documentation about the ACL's and I haven't found it yet.
Also, I can't understand why so many other users of openldap have so few
problems with ACL's.... I am trying to get this working now for days and
days, without any progress..
I am trying to build some access scheme witrh four levels of access. But
already at the 2nd level I am totally lost.
> >But then again, I am getting more and more confused with trial-and-error
> >processing of these ACL's. It might very well be that I drew wrong
> >conclusions from inconclusive tests.
>
> I suggest you go back to the very basic ACL, such as the one
> provided in the example slapd.conf(5) file provide in the
> distribution (as provided by the project) and then slowily
> add new clauses (using operations and logs to confirm they
> do what you think they should do).
Going back to the basics is one of my standard debugging methods, thank you,
please.
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.
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.
So far so good. PLEASE just tell me: you dumbhead, of course not, because so
and so and so. Becasue this is what I read from the docs I can find!
Especially slapd.conf(5) and the slapd admin guides.
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. Now, THAT
bothers me. the regex 'app=qwido' no where near matches 'oc=isp001,app=qwido'
and so I expect that the defaultaccess is appleid which is none.
Now, Kurt, and others, is there a simple answer to my misunderstanding ? Or
even a complicated one ? Or a good source to help me out of my misery (apart
from lobotomy) ?
I'd really like to know.
Greetings
ace
>
> >You are saying that in mentioned case, where there is a regular expression
> > in the 'to' clause, the self directive is working ??
>
> As far as I know, the "by self" clause works just fine regardless of
> what the particulars of the "to" clause.
>
> Kurt