[Date Prev][Date Next]
Re: [LDAP-SOFTWARE] ACLand regex (matching self)
> Just out of curiousity, is there a reason you aren't using the 2.1 series?
the only reason is that debian woody has 2.0.27 as it's standard.
We could go into a long discussion of this - I'd rather not.
It's just that I am really dumb and use a distro ;)
More seriously, it there is no serious bug in 2.0.27, concerning ACL's, it's
not worth upgrading. If 2.1.x ACL's *really* work differently from 2.0.x,
then I'd consider...!
> Also, I'm not quite clear what you are trying to achieve ACL wise with
> openldap. We had a hard start getting ACL's working at first, but once we
> re-ordered them, they are actually very simple for our needs. I'd be
> willing to give you a hand, if I had a better understanding of what you are
> trying to do. ;)
What I am trying to do is maybe best explained in a picture.
(see attachment).(couldn't send the atrtachment due to list restrictions)
The picture is not really accurate, but it gives some overlapping areas of
In text, the idea is:
- the entry app=qwido can only be read by self and oc=.*
- oc=.*,app=qwido can be created by app=qwido
- entries under oc=.* can only be modified by oc=$1
This structure goes on. The explanation is very partial.
I could definitely write the ACL's without any help, if there wasn't this
weird outcome of all my testing !
Here's the partial acl i had:
# qwido 2.0 copyright Ace Suares http://www.qwido.com
# there are 4 levels:
# 1: qwido
# 2: oc
# 3: domain
# 4: user
# 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
### main-manager and sub-managers can write under oc
access to dn="oc=(.*),app=qwido" attrs=children
by group="group=managers,oc=$1,app=qwido" write
by dn="oc=$1,app=qwido" write
by dn.exact="app=qwido" read
### main-manager and sub-managers can read the oc entry
access to dn="oc=(.*),app=qwido"
by group="group=managers,oc=$1,app=qwido" read
by dn="oc=$1,app=qwido" read
by dn.exact="app=qwido" read
### qwido level
access to dn="app=qwido" attrs=children
by dn="app=qwido" write
access to dn="app=qwido"
by dn="app=qwido" read
while testing it, the first thing that got really weird is that the LAST
rule, which should give read access to the entry 'app=qwido' to the dn
'app=qwido' , worked unexpectedly. It actually gave access to the whole
subtree. And it also gave dn='manager=manager001,app=qwido' access to the
(I described that problem earlier).
Then, these things about the RootDSE came up in the discussion.
I granted access to the rootDSE by * read, but problems persisted.
If you are willing to test my setup in a sandbox (this means: a non-critical
emvironemnt!) I would send the scripts to you individuals who want to test.
(I already sent it to Kurt Z, but I can imagine he doesn't even open that
I still suspect that there is something very simple I am overlooking.
Maybe creating an ACL list on openldap.org to channel all energy that goes
into ACL discussion is a good idea ???
I would also vow for a document-writing experiment using freetext (which is
something like an annotated document writing application) on ACL's.
Quanah, could you disclose your ACL ? Does it mention access to rootDSE, or
acces to any other objects mentioned in RFC 2251 ?
If not., there must be something wrong with my setup.
I'm glad some people on this list picked up on this issue. I hope we can
create a comprehensive document on ACL's which execeeds the usefullness of
the current documentation and that we can integrate this into mainstream