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