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

Re: ACIs and OL 2.3

Turbo Fredriksson wrote: 
I got my 2.3.32 compiled and working on saturday,
and I've been playing with it since.

One thing that I stumbled on was the ACI's. I make
heavy usage of that (ever since 2.0 - as a third party
patch I think - or early 2.1 at least).

Then you seem to be the __only__ active user of ACIs, or at least the only one to upgrade ever since, because they've been reworked quite a long ago (check the first appearance of servers/slapd/aci.c in re23: Wed Aug 17 15:14:57 2005 UTC; 17 months, 3 weeks ago...).

But my database
from 2.2 didn't want to load because of OpenLDAPaci
problems...

This is what my aci looks like on the root object:
----- s n i p -----
OpenLDAPaci: 0#entry#grant;r,s,c;objectClass,userReference,[entry]#public#
OpenLDAPaci: 1#entry#grant;r,s,c;useControls,useEzmlm,useBind9,useWebSrv,autoR
 eload,allowServerChange,whoAreWe,language,hostMaster,ezmlmBinaryPath,krb5Real
 mName,krb5AdminServer,krb5PrincipalName,krb5AdminKeytab,krb5AdminCommandPath,
 controlBaseDn,ezmlmAdministrator,controlsAdministrator,useACI#users#
OpenLDAPaci: 2#entry#grant;w,r,s,c,x;[all]#access-id#uid=turbo,ou=People,o=Fre
 driksson,c=SE
----- s n i p -----

This is aparently not allowed, in many ways! You can't
seem to 'stack' the attributes any more.

Well, since I don't have 'Net access in my apartment
in Lisbon, I had to figure this out by trial and error.
I ended up with something like this:
----- s n i p -----
OpenLDAPaci: 0#entry#grant;r,s,c;objectClass#public#
OpenLDAPaci: 1#entry#grant;r,s,c;userReference#public#
OpenLDAPaci: 2#entry#grant;r,s,c;[entry]#public#
OpenLDAPaci: 3#entry#grant;r,s,c;useControls#users#
OpenLDAPaci: 4#entry#grant;r,s,c;useEzmlm#users#
OpenLDAPaci: 5#entry#grant;r,s,c;useBind9#users#
OpenLDAPaci: 6#entry#grant;r,s,c;useWebSrv#users#
OpenLDAPaci: 7#entry#grant;r,s,c;autoReload#users#
OpenLDAPaci: 8#entry#grant;r,s,c;allowServerChange#users#
OpenLDAPaci: 9#entry#grant;r,s,c;whoAreWe#users#
OpenLDAPaci: 10#entry#grant;r,s,c;language#users#
OpenLDAPaci: 11#entry#grant;r,s,c;hostMaster#users#
OpenLDAPaci: 12#entry#grant;r,s,c;ezmlmBinaryPath#users#
OpenLDAPaci: 13#entry#grant;r,s,c;krb5RealmName#users#
OpenLDAPaci: 14#entry#grant;r,s,c;krb5AdminServer#users#
OpenLDAPaci: 15#entry#grant;r,s,c;krb5PrincipalName#users#
OpenLDAPaci: 16#entry#grant;r,s,c;krb5AdminKeytab#users#
OpenLDAPaci: 17#entry#grant;r,s,c;krb5AdminCommandPath#users#
OpenLDAPaci: 18#entry#grant;r,s,c;controlBaseDn#users#
OpenLDAPaci: 19#entry#grant;r,s,c;ezmlmAdministrator#users#
OpenLDAPaci: 20#entry#grant;r,s,c;controlsAdministrator#users#
OpenLDAPaci: 21#entry#grant;r,s,c;useACI#users#
OpenLDAPaci: 22#entry#grant;w,r,s,c,x;[all]#access-id#uid=turbo,ou=People,o=Fre
 driksson,c=SE
----- s n i p -----
which is much uglier...

But still, and this is a reall show stopper - have not been
able to work around this, this don't seemed to work propperly
either! It's the OID 2 that's problem here. The '[entry]'
isn't allowed and I can't seem to find it in the code either.
The check for it any way - all the code say is:

    could be "[all]" or an attribute description

This means that i can't don't have enough access for _creating_
an object, only to _modify_ an existing one...

AFAIR, existing functionalities have been maintained, apart from the possibility to list multiple comma-separated attributes, since the original documentation explicitly excluded it. However, someone (sorry I'm unable to credit him) provided a patch, which is now in HEAD, which restores that behavior. You should find the related ITS. Backporting that patch to re23 was not an issue since nobody complained about it. With respect to [entry], I have no idea. I suspect the original implementation (which was as buggy as it was forgiving) just didn't complain about [entry] bot didn't do anything special about it.


Creating a simple object like this:
----- s n i p -----
dn: o=phpQLAdmin_Branch_Test,c=se
objectclass: top
objectclass: organization
o: phpQLAdmin_Branch_Test
openldapaci: 0#entry#grant;w,r,s,c;[all]#access-id#uid=turbo,ou=people,o=fredriksson,c=se
----- s n i p -----

Fails because of:
----- s n i p -----
adding new entry "o=phpQLAdmin_Branch_Test,c=se"
ldap_add: Insufficient access (50)
        additional info: no write access to entry
----- s n i p -----

Adding the line:
----- s n i p -----
openldapaci: 1#entry#grant;w,r,s,c;[entry]#access-id#uid=turbo,ou=people,o=fredriksson,c=se
----- s n i p -----

Will only give me:
----- s n i p -----
ldap_add: Invalid syntax (21)
        additional info: openldapaci: value #1 invalid per syntax
----- s n i p -----

So... Is there a document that describes the _changes_ to previous
workings of OpenLDAPaci? Or exactly how it's supposed to work now?

Also, is my initial findings that there now have to be one attribute
per 'line' true? Seems very .. complicated ways of doing it... ?

By quickly reading the code, it seems that the effect you desire is obtained by setting no attribute type, or by using "entry" instead of "[entry]".

I suggest you test HEAD code to see if it fits your needs; if it does, you could enucleate a patch that backports desired features to re23, and post it to the ITS. Otherwise, you should file an ITS, requesting backporting of the desired features that are in HEAD along with their fix (if it's buggy) or enhancement (if discussion about what you consider an enhancement gains consensus).

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------