openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 07 Aug '12

07 Aug '12

This ITS can be closed. See ITS#7347 instead, currently located http://www.openldap.org/its/index.cgi/Incoming?id=7347;selectid=7347#follow…

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 07 Aug '12

07 Aug '12

I've uploaded a quick workaround to check the above acl, it can be downloaded from here: ftp://ftp.openldap.org/incoming/its7347.patch => Test result: It works for me. In the sense of the ITS title it's just a half-way workaround: It addresses only subtractive ACLs, additive ACLs are not addressed. A clean solution, separating the bitmasks is of course preferable. In my opinion ITS#6900 should be closed.

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by Kurt＠OpenLDAP.org 07 Aug '12

07 Aug '12

On Aug 6, 2012, at 1:55 PM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) > > > The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 > paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, > Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very > useful in our opinion. > > We (Peter an me) have discussed the idea behind this enhancement together with > Howard during dinner the day before the LDAPCon2011 officially started. We > described the enhancement as some kind of > "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". > > Until today ITS#6900 contains a prototypical patch (very dirty hack), to > demonstrate the described enhancement's mode of operation. > > The good news: > Probably this hack isn't needed anymore in the future and thus ITS#6900 could be > closed, but just in case ... > > The bad news: > ... another (hopefully) less intrusive and generally useful patch, that seems to > be implementable without introducing new keywords can be realized instead: > > In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt > explained that the acl privilege levels "a" and "z" share one bit with the "w" > privilege's bit set. Thus currently neither "a" nor "z" can be independently > substracted from "w" in the way either "z" or "a" remains in the privilege set. > Subtracting "a" or "z" results in removing the complete "w" privilege (including > "a" and "z"). Looking back at the devel discussion about the introduction of a/z privs (April 2005), there seems to have been no consideration of subtractive access controls. That is, I think the we all just missed the a/z feature was not implemented in a manner which supported subtractive access controls. Or, more simply put, whoops. Using qualifiers was the mistake. Just should of replaced one bit with 2 bits, with some operations requesting one or the other or both bits. > In case the bit masks of the privileges "a", "z", and "w" can be separated > (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the > following acl set offers the above described mode of operation (out-of-the-box > without the need to apply the hack submitted with ITS#6900): > > {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none > {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue > by dnattr=modifiersName -z by * none > {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write > by * none > > I've not been able to test this acls yet (due to no available hack/patch). At > least in theory it should represent the mentioned enhancement's mode of > operation: > The owner attribute can be modified (add and delete) by any owner, but no owner > can remove himself from the owner attribute to either repudiate his personal > responsibility for an entry or to produce a dangling entry (an administrator > needs to clean up), in case it's the last owner. I'd have to think a bit harder whether the access controls above implement this properly, but I am sure {1} can be written using non-substractive ACLs. Off hand, probably requiring two to do it. > Herewith, the request for a more detailed description of a usecase where > substractive privileges are of general use should be answered. The general use case of additive and subtractive ACL is that it sometimes makes ACLs shorter. > Additionally I > also thought about the statement, that "good ACLs" are either static or > additive: I think I used the word "should", as in subtractive ACLs should be avoided. There are likely cases where their use can be well justified, just like default grant rules can sometimes be well justified. However, many security experts advise use of explicit grants (=) or additive (+) grants. I generally concur with this advice. > I have not been able to find a static or additive ACL solution to > implement the above described functionality in a similar elegant way (e.g. > without administratively maintained group patterns) > > Alternative 1: (elegant static/additive ACL) > There possibly exists a solution to express the above described mode of > operation already nowadays by using static and additive acls only, if so, I > appreciate any advice. > > Alternative 2: (coding the bitmask-separation) > I have no clue how(h)ard ;-) it is to implement (especially test) a successfull > separation of these bit masks. It was mentioned that the incremental processing > of privileges has been added later and the underlying design could be > suboptimal. Currently I don't know which pitfalls to be aware of (especially in > and around acl.c). Nevertheless and depending on the answer to alternative 1, > I'm interessted to give it a try, thus any thoughts and hints are very welcome, > too. The latter should be the preferred approach, IMO. The question I would have is wether an implementation of such would have any negative impact upon deployments. That's a real hard one to access, as deployments do some pretty crazy things. In short, it comes does to whether anyone does =w continue followed by -a or -z and expecting the outcome not to z or a respectively. -- Kurt > > Thanks a lot! >

1 0

(ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 06 Aug '12

06 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very useful in our opinion. We (Peter an me) have discussed the idea behind this enhancement together with Howard during dinner the day before the LDAPCon2011 officially started. We described the enhancement as some kind of "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". Until today ITS#6900 contains a prototypical patch (very dirty hack), to demonstrate the described enhancement's mode of operation. The good news: Probably this hack isn't needed anymore in the future and thus ITS#6900 could be closed, but just in case ... The bad news: ... another (hopefully) less intrusive and generally useful patch, that seems to be implementable without introducing new keywords can be realized instead: In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt explained that the acl privilege levels "a" and "z" share one bit with the "w" privilege's bit set. Thus currently neither "a" nor "z" can be independently substracted from "w" in the way either "z" or "a" remains in the privilege set. Subtracting "a" or "z" results in removing the complete "w" privilege (including "a" and "z"). In case the bit masks of the privileges "a", "z", and "w" can be separated (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the following acl set offers the above described mode of operation (out-of-the-box without the need to apply the hack submitted with ITS#6900): {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue by dnattr=modifiersName -z by * none {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write by * none I've not been able to test this acls yet (due to no available hack/patch). At least in theory it should represent the mentioned enhancement's mode of operation: The owner attribute can be modified (add and delete) by any owner, but no owner can remove himself from the owner attribute to either repudiate his personal responsibility for an entry or to produce a dangling entry (an administrator needs to clean up), in case it's the last owner. Herewith, the request for a more detailed description of a usecase where substractive privileges are of general use should be answered. Additionally I also thought about the statement, that "good ACLs" are either static or additive: I have not been able to find a static or additive ACL solution to implement the above described functionality in a similar elegant way (e.g. without administratively maintained group patterns). Alternative 1: (elegant static/additive ACL) There possibly exists a solution to express the above described mode of operation already nowadays by using static and additive acls only, if so, I appreciate any advice. Alternative 2: (coding the bitmask-separation) I have no clue how(h)ard ;-) it is to implement (especially test) a successfull separation of these bit masks. It was mentioned that the incremental processing of privileges has been added later and the underlying design could be suboptimal. Currently I don't know which pitfalls to be aware of (especially in and around acl.c). Nevertheless and depending on the answer to alternative 1, I'm interessted to give it a try, thus any thoughts and hints are very welcome, too. Thanks a lot!

1 0

Re: (ITS#7346) ACL processing: additive privs (using control continue)
by hyc＠symas.com 05 Aug '12

05 Aug '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.167.55.212) > > > For further explainations please vistit this technical-posting: > > http://www.openldap.org/lists/openldap-technical/201208/msg00025.html > > Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given > below. As noted in the referenced email thread, this is working as designed. "continue" controls are only useful when a following clause matches the same subject and specifies incremental privileges. There are no following clauses that match the subject in this case, so the implicit "by * none" at the end of every ACL clause is applied. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7346) ACL processing: additive privs (using control continue)
by daniel＠pluta.biz 04 Aug '12

04 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.167.55.212) For further explainations please vistit this technical-posting: http://www.openldap.org/lists/openldap-technical/201208/msg00025.html Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given below. Thanks a lot ------8<--------- slapd.conf --------8<--------- include /opt/openldap-HEAD/etc/openldap/schema/core.schema pidfile /opt/openldap-HEAD/var/run/slapd.pid argsfile /opt/openldap-HEAD/var/run/slapd.args access to * by self write by users read by anonymous auth database mdb suffix "o=test" rootdn "cn=Manager,o=test" rootpw secret directory /opt/openldap-HEAD/var/openldap-data/test index objectClass eq access to dn.subtree="o=test" attrs=sn by users =s continue by group/groupOfNames/member="cn=readers,ou=groups,o=test" +r ------8<--------- sample data --------8<--------- version: 1 dn: o=test objectClass: organization objectClass: top o: test dn: ou=groups,o=test objectClass: organizationalUnit objectClass: top ou: groups dn: ou=persons,o=test objectClass: organizationalUnit objectClass: top ou: persons dn: cn=PersonA,ou=persons,o=test objectClass: person objectClass: top cn: PersonA sn: PersonA userPassword:: UGVyc29uQQ== dn: cn=PersonB,ou=persons,o=test objectClass: person objectClass: top cn: PersonB sn: PersonB userPassword:: UGVyc29uQg== dn: cn=readers,ou=groups,o=test objectClass: groupOfNames objectClass: top cn: readers member: cn=PersonA,ou=persons,o=test ------8<---------Tests using ldapsearch--------8<--------- #Test 1 seem to work as intended: # bindDn "cn=PersonA,..." is member of group "cn=readers,..." # filter: sn=* # search succeeds (that's ok) # read succeeds (that's ok, too) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonA,ou=persons,o=test" -w PersonA -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # PersonA, persons, test dn: cn=PersonA,ou=persons,o=test sn: PersonA cn: PersonA # PersonB, persons, test dn: cn=PersonB,ou=persons,o=test cn: PersonB sn: PersonB # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 #slapd's log (level 128): 501be157 => access_allowed: result not in cache (userPassword) 501be157 => access_allowed: auth access to "cn=PersonA,ou=persons,o=test" "userPassword" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr userPassword 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "userPassword" requested 501be157 => acl_mask: to value by "", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= check a_dn_pat: anonymous 501be157 <= acl_mask: [3] applying auth(=xd) (stop) 501be157 <= acl_mask: [3] mask: auth(=xd) 501be157 => slap_access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs #Test 2 does not seem to work as intended (at least to me): # bindDn "cn=PersonB,..." not a member of group "cn=readers,..." # filter: sn=* # read fails (that's ok) # search fails (but why is the privilege "=s" reset?) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonB,ou=persons,o=test" -w PersonB -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # search result search: 2 result: 0 Success # numResponses: 1 #slapd's log (level 128): 501be196 => access_allowed: result not in cache (userPassword) 501be196 => access_allowed: auth access to "cn=PersonB,ou=persons,o=test" "userPassword" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr userPassword 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "userPassword" requested 501be196 => acl_mask: to value by "", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= check a_dn_pat: anonymous 501be196 <= acl_mask: [3] applying auth(=xd) (stop) 501be196 <= acl_mask: [3] mask: auth(=xd) 501be196 => slap_access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr entry 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [2] applying read(=rscxd) (stop) 501be196 <= acl_mask: [2] mask: read(=rscxd) 501be196 => slap_access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules

1 0

(ITS#7345) New Feature : Add Connection Information in Access Log Entries
by ldap＠htam.net 03 Aug '12

03 Aug '12

Full_Name: Mathieu MILLET Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/accesslog_addConnectionInformation.patch Submission from: (NULL) (82.67.21.31) Entries provided by the Access Log Overlay does not contain informations such as the IP Address of the client. This patch adds a simple attribute : reqConnInfo containing the content of o_conn->c_peer_name . Please review this patch because I'm not sure about what safety checks must be performed on these data before "merging" them. If this patch is accepted : I, Mathieu MILLET, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by hyc＠symas.com 02 Aug '12

02 Aug '12

Eric Clements wrote: > I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. If you have a working patch that behaves as you think it should, you're welcome to submit it. Unfortunately, the RFC is explicitly silent on how other identity formats are represented. I.e., it doesn't even specify that SASL identities (such as used in SASL Bind) are valid here. > Though your statement is true, many SASL methods do not use DNs either. I > do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. > > Thank you, > --------------------------- > Eric Clements > > On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > >> eclements(a)apple.com wrote: >>> Full_Name: Eric Clements >>> Version: 2.4.26 >>> OS: MacOS >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (17.193.15.131) >>> >>> >>> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >>> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. >> >> I'm not sure I understand why you've filed this ITS. The RFC doesn't specify >> that a server MUST support non-DN valued identities. It in fact says in Section 3: >> >> If the server does not recognize provided fields or does not support >> the combination of fields provided, it SHALL NOT change the user >> password. >> >> Clearly it is allowed for a server to reject identities if it doesn't >> recognize them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by eclements＠apple.com 02 Aug '12

02 Aug '12

I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. Though your statement is true, many SASL methods do not use DNs either. I do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. Thank you, --------------------------- Eric Clements On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > eclements(a)apple.com wrote: >> Full_Name: Eric Clements >> Version: 2.4.26 >> OS: MacOS >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (17.193.15.131) >> >> >> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. > > I'm not sure I understand why you've filed this ITS. The RFC doesn't specify > that a server MUST support non-DN valued identities. It in fact says in Section 3: > > If the server does not recognize provided fields or does not support > the combination of fields provided, it SHALL NOT change the user > password. > > Clearly it is allowed for a server to reject identities if it doesn't > recognize them. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7344) [PATCH] Add initial testsuit for slapo-constraint
by hyc＠symas.com 02 Aug '12

02 Aug '12

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: linux-fedora17 > URL: ftp://ftp.openldap.org/incoming/jsynacek-20120802-testsuit-slapo-constraint… > Submission from: (NULL) (209.132.186.34) > > > This patch adds an initial testsuit for slapo-constraint. Thanks, added to master. > > The attached file is derived from OpenLDAP Software. All of the modifications > to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Synacek am authorized by Red Hat, my employer, to release this work > under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs