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). 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...
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... ?
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 descriptionThis 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 ------------------------------------------
Quoting Pierangelo Masarati ando@sys-net.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 -----
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 -----
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]".
Neither of this work. The first with 'no write access to entry' and the second with 'openldapaci: value #0 invalid per syntax'.
----- 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;entry#public# openldapaci: 1#entry#grant;w,r,s,c;[all]#access-id#uid=turbo,ou=people,o=fredriksson,c=se ----- s n i p -----
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).
Shouldn't the '[all]' should cover all this? If I get/have ALL access on the object, shouldn't that include entry and all it's attributes!?
I'm not quite sure how it is SUPPOSED to work, but from my view, it's broken - ACI's don't work with re23 which is a stable release... ? Using ACI's, I have to access to create objects - that's what I see any way...
And the little documentation there is on the subject doesn't tell me that I'm using it wrongly (I can live with the changes to 'one attribute per openldapaci - quite easy to programatically change).
I can have a look at HEAD, but...
Turbo Fredriksson wrote:
I'm not quite sure how it is SUPPOSED to work, but from my view, it's broken - ACI's don't work with re23 which is a stable release... ? Using ACI's, I have to access to create objects - that's what I see any way...
Well, nobody knows how it's supposed to work, since the expected behavior is undocumented.
And the little documentation there is on the subject doesn't tell me that I'm using it wrongly (I can live with the changes to 'one attribute per openldapaci - quite easy to programatically change).
I can have a look at HEAD, but...
Let's put it the other way: HEAD and re23 code differ. From your point of view, re23 is broken. If you check HEAD and from your point of view it works, then we made an incredibly large progress towards fixing your problem. If you don't check HEAD and we manage to fix re23, your problem will be back when you'll need to move to re24. That's why help from testers on rarely used features is important __before__ a release is released. We are approaching end of life of re23 and you realize just now that ACIs are broken, and they didn't see any significant change for the life duration of re23. This is going to go on forever at each version change.
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 ------------------------------------------
On Tue, Feb 13, 2007 at 06:50:02PM +0100, Pierangelo Masarati wrote:
Turbo Fredriksson wrote:
I'm not quite sure how it is SUPPOSED to work, but from my view, it's broken - ACI's don't work with re23 which is a stable release... ? Using ACI's, I have to access to create objects - that's what I see any way...
Well, nobody knows how it's supposed to work, since the expected behavior is undocumented.
Hi
Is there any doco on this, I don't know anything about it, could your provide a pointer to some info.
I am presume this is a way of apply acl's to objects ?
<snip>
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
Alex Samad wrote:
On Tue, Feb 13, 2007 at 06:50:02PM +0100, Pierangelo Masarati wrote:
Turbo Fredriksson wrote:
I'm not quite sure how it is SUPPOSED to work, but from my view, it's broken - ACI's don't work with re23 which is a stable release... ? Using ACI's, I have to access to create objects - that's what I see any way...
Well, nobody knows how it's supposed to work, since the expected behavior is undocumented.
Hi
Is there any doco on this, I don't know anything about it, could your provide a pointer to some info.
Browse http://www.openldap.org/faq/data/cache/1284.html in general for OpenLDA access control customization capabilities, and http://www.openldap.org/faq/data/cache/758.html for more details about ACIs. Note, that document is pretty old; something changed across time (which caused this thread, BTW). ACIs need to be documented; our reluctance also stems from the consideration that good documentation would encourage rather than discourage their use... anyway, volunteers are welcome.
I am presume this is a way of apply acl's to objects ?
Yes (experimental, deprecated and discouraged).
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 ------------------------------------------
--On Wednesday, February 14, 2007 12:24 AM +0100 Pierangelo Masarati ando@sys-net.it wrote:
Alex Samad wrote:
On Tue, Feb 13, 2007 at 06:50:02PM +0100, Pierangelo Masarati wrote:
Turbo Fredriksson wrote:
I'm not quite sure how it is SUPPOSED to work, but from my view, it's broken - ACI's don't work with re23 which is a stable release... ? Using ACI's, I have to access to create objects - that's what I see any way...
Well, nobody knows how it's supposed to work, since the expected behavior is undocumented.
Hi
Is there any doco on this, I don't know anything about it, could your provide a pointer to some info.
Browse http://www.openldap.org/faq/data/cache/1284.html in general for OpenLDA access control customization capabilities, and http://www.openldap.org/faq/data/cache/758.html for more details about ACIs. Note, that document is pretty old; something changed across time (which caused this thread, BTW). ACIs need to be documented; our reluctance also stems from the consideration that good documentation would encourage rather than discourage their use... anyway, volunteers are welcome.
I am presume this is a way of apply acl's to objects ?
Yes (experimental, deprecated and discouraged).
I think this is the very important part here -- deprecated and discouraged. I'd argue that long term, ACI support should be removed entirely (perhaps for 2.5?). The entire concept of ACI's is broken.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Quanah Gibson-Mount wrote:
I am presume this is a way of apply acl's to objects ?
Yes (experimental, deprecated and discouraged).
I think this is the very important part here -- deprecated and discouraged. I'd argue that long term, ACI support should be removed entirely (perhaps for 2.5?). The entire concept of ACI's is broken.
In 2.4 it __is__ removed: it's a separate module, which needs to be explicitly loaded by the administrator. Currently, some provision for statically building it into slapd remains, as soon as one --enable-dynacl.
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 ------------------------------------------
Quoting Pierangelo Masarati ando@sys-net.it:
http://www.openldap.org/faq/data/cache/758.html for more details about ACIs. Note, that document is pretty old; something changed across time (which caused this thread, BTW). ACIs need to be documented; our reluctance also stems from the consideration that good documentation would encourage rather than discourage their use... anyway, volunteers are welcome.
I'll try to put in a couple of cents (euro though :) worth as soon as I get more accustomed to the new layout...
I am presume this is a way of apply acl's to objects ?
Yes (experimental, deprecated and discouraged).
Deprecated you say... Anything else that I can use to get this behaviour (no restart because of access control change)?
Quoting Pierangelo Masarati ando@sys-net.it:
Let's put it the other way: HEAD and re23 code differ. From your point of view, re23 is broken. If you check HEAD and from your point of view it works, then we made an incredibly large progress towards fixing your problem.
re23 is broken, and HEAD won't compile...
This is exactly the reason why I waited with the upgrade. I don't have time to play...
tests/progs/slapd-search.c: In function 'do_random': tests/progs/slapd-search.c:301: error: 'EXIT_FAIL' undeclared (first use in this function) tests/progs/slapd-search.c:301: error: (Each undeclared identifier is reported only once tests/progs/slapd-search.c:301: error: for each function it appears in.)
Turbo Fredriksson wrote:
Quoting Pierangelo Masarati ando@sys-net.it:
Let's put it the other way: HEAD and re23 code differ. From your point of view, re23 is broken. If you check HEAD and from your point of view it works, then we made an incredibly large progress towards fixing your problem.
re23 is broken, and HEAD won't compile...
This is exactly the reason why I waited with the upgrade. I don't have time to play...
tests/progs/slapd-search.c: In function 'do_random': tests/progs/slapd-search.c:301: error: 'EXIT_FAIL' undeclared (first use in this function) tests/progs/slapd-search.c:301: error: (Each undeclared identifier is reported only once tests/progs/slapd-search.c:301: error: for each function it appears in.)
That was fixed two hours ago (it was broken for minutes, as far as I can tell; moreover, slapd-search is part of the test suite; if you got there, what counts is already built). re23 was fixed half an hour ago (before I asked you to retry).
I do not pretend many thanks for spending __my__ time on __your__ problem, but please at least don't try to play fool of me.
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 ------------------------------------------
Turbo Fredriksson wrote:
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]".
Neither of this work. The first with 'no write access to entry' and the second with 'openldapaci: value #0 invalid per syntax'.
A more careful pass thru the code shows that actually, "[entry]" is not tolerated by normalization functions, while "entry" is. But later on, checking for "entry" is turned into "[entry]" (catch 22?).
On the contrary, using "[all]" works as expected.
I've fixed that in re23. Much like in HEAD, now "[entry]" is tolerated in input, but it gets normalized into "entry" (so don't get surprised nor disappointed when you look at your newly added ACIs). Further checking always uses "entry".
You should note some other odds in input/output, since normalization/prettification is consistently used on ACI values. You might also notice some performance improvement, since now access checking heavily relies on the presence of normalized values.
Normalization rules shouldn't have changed, so there should be no need to dump/reload your database.
The multiple attribute feature is gone in 2.3 (it's back in 2.4: see ITS#4759). However, 2.3 and later have another feature: you can add multiple sets of "perms;attr" groups, like
openldapaci: 0#entry#grant;w,r,s,c;entry;r,s,c;objectClass#public#
and so on.
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 ------------------------------------------
Quoting Pierangelo Masarati ando@sys-net.it:
On the contrary, using "[all]" works as expected.
With this I take it that '[all]' isn't supposed to give you access to the entry itself? I'm not supprised actually, it kind'a makes sence - why else have 'entry'? :)
I've fixed that in re23.
Thanx a lot! I tried to do that myself (just take aci.c from HEAD), but that had way to many other changes so I gave up on that. And I wasn't quite sure where/what to take... Looked a little to much 'internal OpenLDAP magic' to me :).
Much like in HEAD, now "[entry]" is tolerated in input, but it gets normalized into "entry" (so don't get surprised nor disappointed when you look at your newly added ACIs). Further checking always uses "entry".
I don't care either way actually. Either is fine by me. For future use (re24), which should I use?
You should note some other odds in input/output, since normalization/prettification is consistently used on ACI values. You might also notice some performance improvement, since now access checking heavily relies on the presence of normalized values.
Sorry, but can you take that again, slower? :) I'm not going to say it looked like greek - I don't want to have my head bitten of, or a greek dictionary shoved down my thought :) But either I'm very tired, or I'm not myself today...
Normalization rules shouldn't have changed, so there should be no need to dump/reload your database.
Between re22 and re23? Or re23 and re24? I did the dump/reload because I took my production database and tried to load it on my development platform so I could test out re23... And I actually think I'll wait with the upgrade of the production machines until I've helped out testing re24...
The multiple attribute feature is gone in 2.3 (it's back in 2.4: see ITS#4759).
Thanx. Since re23 'is near end of life', I'll just play with 2.3 on my development platform(s) and wait/helpt test for re24...
However, 2.3 and later have another feature: you can add multiple sets of "perms;attr" groups, like
openldapaci: 0#entry#grant;w,r,s,c;entry;r,s,c;objectClass#public#
That I saw both in the source and in the example/test script. But I found that even worse/uglier so I'll stick with the single attribute per 'line' (for playing with new features in 2.3 - preparing myself for 2.4).
Turbo Fredriksson wrote:
You should note some other odds in input/output, since normalization/prettification is consistently used on ACI values. You might also notice some performance improvement, since now access checking heavily relies on the presence of normalized values.
Sorry, but can you take that again, slower? :)
The point is that starting with re23, ACI values in the database are assumed to be normalized. When evaluating access checking, each value is parsed under that assumption, so minimal consistency checking is done. This is supposed to:
- early detect inconsistencies; earlier, (almost) any value was accepted without checks; errors would possibly be detected while evaluating access, and values that couldn't be parsed would be sort of ignored
- reduce the effort required to evaluate access: DNs no longer need to be normalized for __every__access control, and things like that
Normalization rules shouldn't have changed, so there should be no need to dump/reload your database.
Between re22 and re23? Or re23 and re24?
between re23 and re23 after this fix. If normalization rules change, values that already are in the database, and are assumed to be fine, may no longer be valid. This would require a complete dump and reload of the database to make sure that the new normalization rules are in effect. This should not be the case, since the change that's now in re23 does not restrict the syntax; it actually looses it, so more values are accepted, but resulting in the same normalized form.
Of course, as stated in the OpenLDAP license, you're on your own, there's no warranty that no database reload is required ;).
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 ------------------------------------------
Quoting Pierangelo Masarati ando@sys-net.it:
Turbo Fredriksson wrote:
You should note some other odds in input/output, since normalization/prettification is consistently used on ACI values. You might also notice some performance improvement, since now access checking heavily relies on the presence of normalized values.
Sorry, but can you take that again, slower? :)
The point is that starting with re23, ACI values in the database are assumed to be normalized. When evaluating access checking, each value is parsed under that assumption, so minimal consistency checking is done.
So in other words, I have to normalize the ACI's _before_ adding it to the database? Or is it done by slapadd/ldapadd/ldap_add()?
- reduce the effort required to evaluate access: DNs no longer need to
be normalized for __every__access control, and things like that
Hmm... This sounds/looks like a contradiction... 'db is assumed to be normalized' and 'DNs no longer need to be normalized'... ?
Btw, normalization, is that just lower-casing 'everything' and making DN's 'correct' (no excess spaces etc)?
Turbo Fredriksson wrote:
Quoting Pierangelo Masarati ando@sys-net.it:
Turbo Fredriksson wrote:
You should note some other odds in input/output, since normalization/prettification is consistently used on ACI values. You might also notice some performance improvement, since now access checking heavily relies on the presence of normalized values.
Sorry, but can you take that again, slower? :)
The point is that starting with re23, ACI values in the database are assumed to be normalized. When evaluating access checking, each value is parsed under that assumption, so minimal consistency checking is done.
So in other words, I have to normalize the ACI's _before_ adding it to the database? Or is it done by slapadd/ldapadd/ldap_add()?
Normalization is done automatically by slapd, as it always has been. You don't have to do anything special. None of what was mentioned in these posts is user-visible, aside from the performance improvement.
- reduce the effort required to evaluate access: DNs no longer need to
be normalized for __every__access control, and things like that
Hmm... This sounds/looks like a contradiction... 'db is assumed to be normalized' and 'DNs no longer need to be normalized'... ?
In 2.0 and 2.1 normalized attribute values were only stored in memory, not saved to the database. So when an entry was freshly read from the DB, all of the normalization had to be repeated.
Since 2.2 the normalized values are stored in the database, so normalization only occurs once for any attribute (when its values are first input).
Btw, normalization, is that just lower-casing 'everything' and making DN's 'correct' (no excess spaces etc)?
No. Normalization for an attribute depends on its syntax. Obviously values with case-sensitive syntaxes do not get lower-cased.
And again, these are internal implementation details, not user-visible. You should just forget you ever saw this part of the discussion.
Quoting Howard Chu hyc@symas.com:
Turbo Fredriksson wrote:
Btw, normalization, is that just lower-casing 'everything' and making DN's 'correct' (no excess spaces etc)?
And again, these are internal implementation details, not user-visible. You should just forget you ever saw this part of the discussion.
Ok, thanx. *ping*. Forgotten...
What where we talking about?! Nothing to see here, move along... :)
Btw, I tried OPENLDAP_REL_ENG_2_3 (checked out yesterday) and it worked just fine! So did HEAD... Although HEAD had some other 'problems' (which was due to user-errors - not reading the documentation about changes in setup etc :).
I just document in my app that >2.3.32 is needed... Thanx again for all the help!
Turbo Fredriksson wrote:
Quoting Pierangelo Masarati ando@sys-net.it:
Turbo Fredriksson wrote:
You should note some other odds in input/output, since normalization/prettification is consistently used on ACI values. You might also notice some performance improvement, since now access checking heavily relies on the presence of normalized values.
Sorry, but can you take that again, slower? :)
The point is that starting with re23, ACI values in the database are assumed to be normalized. When evaluating access checking, each value is parsed under that assumption, so minimal consistency checking is done.
So in other words, I have to normalize the ACI's _before_ adding it to the database? Or is it done by slapadd/ldapadd/ldap_add()?
They are normalized by the write process; you supply them as you like, and slapd normalizes them as appropriate. You don't need to know anything about normalization.
- reduce the effort required to evaluate access: DNs no longer need to
be normalized for __every__access control, and things like that
Hmm... This sounds/looks like a contradiction... 'db is assumed to be normalized' and 'DNs no longer need to be normalized'... ?
Only to a careless reader. If ACI values are stored without normalization, portions of them that require normalization to be compared, like DNs, have to be normalized __each time they're used__.
On the contrary, if ACI values (actually, components that need normalization) are normalized when written, their use does not require any further action.
Btw, normalization, is that just lower-casing 'everything' and making DN's 'correct' (no excess spaces etc)?
Normalization is anything required by the equality matchingRule defined for an attribute, if any. You don't need to care about that.
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 ------------------------------------------
Regarding "broken ACI concept" - does any rfc speaks something about concept of dynamically assigned priviledges to ldap directory entries? Or does it recommend avoiding such policies? Regards, Piotr
On Wednesday 14 February 2007 12:10, Piotr Wadas wrote:
Regarding "broken ACI concept" - does any rfc speaks something about concept of dynamically assigned priviledges to ldap directory entries? Or does it recommend avoiding such policies?
To my knowledge there is no RFC on this topic. There are (or rather were) however some internet drafts that talk about LDAP Access Control Models. The current ACI implementation in OpenLDAP is AFAIK to some extend similar (but only to some extend) to what is described in draft-ietf-ldapext-acl-model-xx.txt.
Another Access Control Model is described in draft-legg-ldap-acm-bac-xx.txt, which is an adaption of the X.500 Basic Access Control and Simple Access Control scheme to LDAP.
Note, however that both drafts expired already some time ago.
Piotr Wadas wrote:
Regarding "broken ACI concept" - does any rfc speaks something about concept of dynamically assigned priviledges to ldap directory entries? Or does it recommend avoiding such policies?
AFAIK, nothing made it into an RFC; what OpenLDAP's ACIs are (loosely) based on is <draft-ietf-ldapext-aci-model-0.3.txt>. Other implementors do have ACIs and, in some cases, they're the preferred means to control access. This doesn't mean ACIs has to be the preferred implementation of access control.
IMHO, the most appealing feature of ACIs is the fact that in principle access rules get replicated along with data. However, the lack of a standard defeats this purpose when getting to cross-implementation replication, migration and so. Moreover, one might want to have different access rules for different shadows of the same database. Finally, right now access control on OpenLDAP's slapd can be modified without the need to stop and restart it, by means of cn=config; there is work in progress to allow configuration replication. As such, OpenLDAP offers better means to achieve the same purpose without ACIs, with the access determinism guaranteed by avoiding the use of ACIs.
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 ------------------------------------------
IMHO, the most appealing feature of ACIs is the fact that in principle access rules get replicated along with data. However, the lack of a standard defeats this purpose when getting to cross-implementation replication, migration and so. Moreover, one might want to have different access rules for different shadows of the same database.
This probably breaks one of ACI principles - that an acl is stored "with the entry itself", as shadow probably means "the same entry shadowed", rather than "shadowed copy of an entry"(?). On the other hand, if ACI would have been designed with object-like manner, some attribute could keep a piece of information about a particular "shadow" it's effective with.
Currently I have a few openldapservers with common entries, and in some cases I replicate only needed branches, anyway, in some other, I rather prefer to add some (multi or single value) attribute like "thisEntryUsedByHost", replicate the whole tree, and on the application which uses particular replica, add some filter in &(thisEntryUsedByHost=my.current.host.name). I don't have any comparable source of information, is something wrong with such usage?
Finally, right now access control on OpenLDAP's slapd can be modified without the need to stop and restart it, by means of cn=config; there is work in progress to allow configuration replication. As such, OpenLDAP offers better means to achieve the same purpose without ACIs, with the access determinism guaranteed by avoiding the use of ACIs.
That's ok, I just started using cn=config lately and I'm not familiar with it, however, isn't there other side of penny - one can modify config information without restarting, but modified information is not stored/saved between restarts ? ACI is somehow "static", although it's not "static" in common sense :)
Regards, Piotr
Piotr Wadas wrote:
That's ok, I just started using cn=config lately and I'm not familiar with it, however, isn't there other side of penny - one can modify config information without restarting, but modified information is not stored/saved between restarts ? ACI is somehow "static", although it's not "static" in common sense :)
Changes thru cn=config are persistent; changes thru cn=monitor, where permitted, aren't.
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 ------------------------------------------
Pierangelo Masarati wrote:
Piotr Wadas wrote:
That's ok, I just started using cn=config lately and I'm not familiar with it, however, isn't there other side of penny - one can modify config information without restarting, but modified information is not stored/saved between restarts ? ACI is somehow "static", although it's not "static" in common sense :)
Changes thru cn=config are persistent; changes thru cn=monitor, where permitted, aren't.
But changes thru cn=config only persist if they have converted from slapd.conf to slapd.d, as noted in the Admin Guide.
Howard Chu wrote:
Pierangelo Masarati wrote:
Piotr Wadas wrote:
That's ok, I just started using cn=config lately and I'm not familiar with it, however, isn't there other side of penny - one can modify config information without restarting, but modified information is not stored/saved between restarts ? ACI is somehow "static", although it's not "static" in common sense :)
Changes thru cn=config are persistent; changes thru cn=monitor, where permitted, aren't.
But changes thru cn=config only persist if they have converted from slapd.conf to slapd.d, as noted in the Admin Guide.
Right, sorry.
Of course I did not consider the possibility to use cn=config without a persistent database. That's possible, but it should not be considered the preferred usage.
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 ------------------------------------------
Quoting Pierangelo Masarati ando@sys-net.it:
Finally, right now access control on OpenLDAP's slapd can be modified without the need to stop and restart it, by means of cn=config;
Sounds cool. I'll have a look at it. But I gather that is just ACL's in the database?
And the very consept of ACL is worse than whatever you can think of regarding ACI's. If I want to give ONE user access to ONE attribute in ONE object (and many such rules), then ACLs would very quickly become ... unmanagable. With ACI's its very obvious and simple...
there is work in progress to allow configuration replication. As such, OpenLDAP offers better means to achieve the same purpose without ACIs, with the access determinism guaranteed by avoiding the use of ACIs.
I argue against the word 'same'. But the meaning of the exact word I guess you're right, I'd say just _a lot_ more complicated/unmanagable in the long run...
Pierangelo Masarati wrote:
IMHO, the most appealing feature of ACIs is the fact that in principle access rules get replicated along with data.
The most appealing feature to me would be that a client could in advance determine what access control is in effect and modify the input forms accordingly. But without a common standard there is no point in using in-directory ACIs.
Ciao, Michael.
Michael Ströder wrote:
Pierangelo Masarati wrote:
IMHO, the most appealing feature of ACIs is the fact that in principle access rules get replicated along with data.
The most appealing feature to me would be that a client could in advance determine what access control is in effect and modify the input forms accordingly. But without a common standard there is no point in using in-directory ACIs.
Couldn't you use Get Effective Rights for that?
Ciao, Michael.
Rich Megginson wrote:
Michael Ströder wrote:
Pierangelo Masarati wrote:
IMHO, the most appealing feature of ACIs is the fact that in principle access rules get replicated along with data.
The most appealing feature to me would be that a client could in advance determine what access control is in effect and modify the input forms accordingly. But without a common standard there is no point in using in-directory ACIs.
Couldn't you use Get Effective Rights for that?
That would be close, maybe good enough for a GUI. But Get Effective Rights can't tell you about value-specific rights.
Howard Chu wrote:
Rich Megginson wrote:
Michael Ströder wrote:
Pierangelo Masarati wrote:
IMHO, the most appealing feature of ACIs is the fact that in principle access rules get replicated along with data.
The most appealing feature to me would be that a client could in advance determine what access control is in effect and modify the input forms accordingly. But without a common standard there is no point in using in-directory ACIs.
Couldn't you use Get Effective Rights for that?
That would be close, maybe good enough for a GUI. But Get Effective Rights can't tell you about value-specific rights.
BTW, we've recently contributed that feature to OpenLDAP:
http://www.openldap.org/its/index.cgi/?findid=4730
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 ------------------------------------------
[...]
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: 1#entry#grant;w,r,s,c;[entry]#access-id#uid=turbo,ou=people,o=fredriksson,c=se
[...]
Actually, what always seems strange to me with ACIs, was, that ACL, whatever it contains actually, is stored inside _one_ attribute value. The following is clear to me:
1. ACL for entry "X" is stored with the entry itself 2. One entry may have zero or more acls stored with it 3. one acl have more than one "sub-values", where somehow valid set of these sub-values of many kinds, build a final _one_ accesslist for an entry
4. (?) whatever one access list is going to contain, it must conform to access list general syntax - it must be always possible to write down ACL of the same meaning, using slapd.conf acl syntax and ACI attribute value syntax.
Now, the question is, why actually ACI access list attribute keeps the whole access list in "one line" (one value of the attribute) ? Access list, anyway, is a set of information, with some not straigt syntax, it keeps at least three kinds of data - "by who", "to where", "what", "grant/deny", etc. etc. (?).
Now, it's the LDAP, right? objective database, class hierarchy etc. So why it's not some object-based strucure for access list, but such "one-line" structure? It reminds me some mysql-like overusaged application, which uses varchar column "mysupervaluecolumn", and put into this column values like "val1", "val1,val5", "val5,val3", instead of creating a table and tune up information graining (ep.. granularity, or whatever the appropriate word was :-)
I'm not openldap developer, anyway I'm developer of somekind, so as I'm probably not aware exactly _how_much_ work is related to access list object-based storage, anyway I'm aware it's very much, and probably much more that parsing some "one_line" value :-). But the question persists, do I miss something? Why ACIs are/were designed this way? Was there some reason, or just that came up? :)
Sorry for misdirect, if this post should go to openldap-devel list :) Regards, Piotr
Piotr Wadas wrote:
Sorry for misdirect, if this post should go to openldap-devel list :)
This type of questions should rather go to an LDAP specific list (like ldap@umich.edu), since (apart from slight implementation details) it has little to do with OpenLDAP software.
All that's about OpenLDAP is that at some point, possibly during the lifespan of <draft-ietf-ldapext-aci-model>, someone patched OpenLDAP's slapd according to that doc. You may want to try looking up discussions about that doc in OpenLDAP's archives; discussion about that draft might have occurred in some IETF list as well.
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 ------------------------------------------
openldap-software@openldap.org
-
Alex Samad -
Howard Chu -
Michael Ströder -
Pierangelo Masarati -
Piotr Wadas -
Quanah Gibson-Mount -
Ralf Haferkamp -
Rich Megginson -
Turbo Fredriksson