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

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

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.acl
# 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
 whole subtree.

(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
 mail ;)

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

_Ace

-------------------------------------------------------