openldap-bugs January 2009

openldap-bugs@openldap.org

50 participants
201 discussions

Re: (ITS#5796) back-sql intermittently failing
by ando＠sys-net.it 24 Jan '09

24 Jan '09

Robert Brooks wrote: > any luck with this? Not even in my priority list right now, sorry. A patch would be welcome. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5884) disclose ACL not safe on non-leaf objects
by jclarke＠linagora.com 24 Jan '09

24 Jan '09

Hi Andrew, andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Jan 12, 2009 at 07:47:20PM +0000, hyc(a)symas.com wrote: > > >>> For example, if I have a DIT like this: >>> >>> dc=example,dc=org--+ >>> +--dc=a--+ >>> | +--dc=people--+ >>> | +--cn=a1 >>> | >>> +--dc=b--+ >>> +--dc=people--+ >>> +--cn=b1 >>> >>> and I give read access on dc=example,dc=org (base) >>> and on dc=a,dc=example,dc=org (subtree) >>> and dc=people,dc=b,dc=example,dc=org (subtree) >>> but no access at all on dc=b,dc=example,dc=org >>> then I would not expect to be able to read the cn=b1 entry, as doing so would >>> expose the existence of dc=b. >>> >>> What actually happens is that any attempt to read dc=b itself returns >>> correctly as if the entry does not exist, but a simple subtree search >>> happily returns cn=b1. >>> > I want to make the discoverability of entries dependent on the value of > an attribute in a parent node, but I cannot see a way of doing it using > the existing ACL syntax and behaviour. > > The closest I have got so far is to use the set syntax in a deny rule: > > # Blockers - look for exampleVisibility=block in all parent entries > # > access to * > by set="this/-*/exampleVisibility & [block]" none > by * break > > This allows any entry to block its subtree to *all* users by setting > exampleVisibility=block > There does not seem to be any way to make the block dependent on > *who* is requesting access, as sets are only valid in the 'by <who>' > part of the rule. > You can refer to *who* in the 'by' part of a set-based rule. Here is an example to limit your "deny" ACL to a category of population: access to * by set="(this/-*/exampleVisibility & [block])/-100 & (user/bypassBlock & [TRUE])/-100" by * break The trick is returning a non empty set. To do this, "/-100" return the 100th parent of each entry. The algorithm is coded so as to return the highest existing parent if it less than 100 degrees away ("dc=org", in your example). However, if one or the other of the sets is empty (ie user doesn't match), this returns an empty set. Obviously, 100 is a conservative value, and some performance improvement may be obtained with a smaller value of 100. Or, a function that makes it less of a hack :) Regards, Jonathan -- Jonathan Clarke -- LinID - Open Source Identity Management --------------------------------------------------------------- Linagora 27 rue de Berri, 75008 Paris Tel: 01 58 18 68 28 / 06 99 60 03 10 --------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org/ ---------------------------------------------------------------

1 0

Re: (ITS#5884) disclose ACL not safe on non-leaf objects
by ando＠sys-net.it 24 Jan '09

24 Jan '09

I think you're sort of overexpecting from this feature. The basic existence of "disclose" within the access privileges means that adiminstrators can get most of the advantage out of it. But think of what you are asking for: you want to be able to say "well, the whole tree must not be disclosable. According to slapd's ACL paradigm, I'll start enumerating access privileges narrow from broad, *but*, for the disclose level, I want it to work broad from narrow. I agree it would be quite useful to be able to just say "access has to be exactly what I have in mind, no more, no less", but somehow you need to be able to translate your expectation in an inevitably limited language that slapd can understand. For this reason, you need to explicitly add "disclose" access whenever you're detailing access to "narrow", since you can't expect "broad" to overcome "narrow" when "narrow" comes first. Hope I made the point. Regardless of what any of us considers the "expected" or the "favored" behavior, slapd's ACLs work like that. Either you write them the way slapd expects them, or you'll get a behavior different from expected. Of course, feel free to propose a totally different, at least identically flexible and more user-friendly way to describe access privileges. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5903) memberof stacked instance member-attr delete failure
by mbackes＠symas.com 24 Jan '09

24 Jan '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: Submission from: (NULL) (76.88.99.93) If slapo-memberof is instanced more than once, deleting the member-attr values from a group or deleting the group object will not remove the memberof-attr values from the members. Adds are not affected. Internally, the operation fails because it tries using the memberof-attribute name from the last memberof instance in the stack. For example, given two member/group oc/attr sets in a schema: objectIdentifier symasExample 1.3.6.1.4.1.4754.31 objectIdentifier symasExAT symasExample:1 objectIdentifier symasExOC symasExample:2 attributetype ( symasExAT:1 NAME 'memberA' SUP distinguishedName ) attributetype ( symasExAT:2 NAME 'memberOfA' SUP distinguishedName ) attributetype ( symasExAT:3 NAME 'memberB' SUP distinguishedName ) attributetype ( symasExAT:4 NAME 'memberOfB' SUP distinguishedName ) objectclass ( symasExOC:1 NAME 'groupA' SUP top STRUCTURAL MUST cn MAY memberA ) objectclass ( symasExOC:2 NAME 'groupMemberA' SUP top AUXILIARY MAY memberOfA ) objectclass ( symasExOC:3 NAME 'groupB' SUP top STRUCTURAL MUST cn MAY memberB ) objectclass ( symasExOC:4 NAME 'groupMemberB' SUP top AUXILIARY MAY memberOfB ) If we add two overlay instances: overlay memberof memberof-group-oc groupA memberof-member-ad memberA memberof-memberof-ad memberOfA memberof-dn cn=memberOfA overlay memberof memberof-group-oc groupB memberof-member-ad memberB memberof-memberof-ad memberOfB memberof-dn cn=memberOfB And start with the data, involving the ocs/attrs from the first instance: dn: cn=person1,o=example objectclass: person objectclass: groupMemberA cn: person1 sn: person1 memberOfA: cn=groupA,o=example dn: cn=groupA,o=example objectclass: groupA cn: groupA memberA: cn=person1,o=example And issue a delete: dn: cn=groupA,o=example changetype: delete Internally we see: bdb_modify_internal: delete memberOfB bdb_modify_internal: 16 modify/delete: memberOfB: no such attribute hdb_modify: modify failed (16) send_ldap_result: conn=0 op=1 p=3 send_ldap_result: err=16 matched="" text="modify/delete: memberOfB: no such attribute" slap_graduate_commit_csn: removing 0x10066cdc0 20090124095138.577730Z#000000#000#000000 conn=0 op=1: memberof_value_modify memberOfB="cn=groupA,o=example" failed err=16 text= send_ldap_response: msgid=2 tag=107 err=0 And cn=person1 has not been cleaned up: dn: cn=person1,o=example objectClass: person objectClass: groupMemberA cn: person1 sn: person1 memberOfA: cn=groupA,o=example modifiersName: o=example -- Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#5896) search error on ldap_search_ext_s
by hyc＠symas.com 23 Jan '09

23 Jan '09

hyc(a)symas.com wrote: > This behavior is by design, and has been in place since 2000. Whether the > design is correct or not may be an open question; since Kurt wrote that code > I'd ask him to comment further. > This is now fixed in CVS HEAD, please test. -- -- 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#5881) referral problem with refreshAndPersist mode
by hyc＠symas.com 23 Jan '09

23 Jan '09

hyc(a)symas.com wrote: > Interesting, you've found a bug that has been present since syncrepl's code > was first written in 2003. The syncrepl code assumes that it will only receive > LDAP entries from the provider. But according to RFC4533, references are > supposed to be sent as-is and stored by the consumer. The syncprov overlay > obeys the spec and sends references correctly. > FIxed now in HEAD. -- -- 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#5881) referral problem with refreshAndPersist mode
by hyc＠symas.com 23 Jan '09

23 Jan '09

joao.alfredo(a)gmail.com wrote: > Full_Name: João Alfredo > Version: 2.4.13 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.189.117.10) > > > I am using a refreshAndPersist replication mode on OpenLdap 2.4.13. > > When I add referral OU on Master, this entrie is not replicate to Consumer. > > My test.ldif: > dn: ou=MUNICIPIOS,dc=pr > ou: MUNICIPIOS > ref: ldap://<IP>/ou=MUNICIPIOS,dc=pr > objectClass: referral > objectClass: extensibleObject > dc: MUNICIPIOS > Logs on consumer side: > Jan 8 17:50:15 ecelepar10173 slapd[2722]: do_syncrep2: rid=000 reference > received error Interesting, you've found a bug that has been present since syncrepl's code was first written in 2003. The syncrepl code assumes that it will only receive LDAP entries from the provider. But according to RFC4533, references are supposed to be sent as-is and stored by the consumer. The syncprov overlay obeys the spec and sends references correctly. -- -- 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: add option for setting minimum TLS/SSL protocol (ITS#5655)
by hyc＠symas.com 23 Jan '09

23 Jan '09

guenther(a)sendmail.com wrote: > I could have sworn I had uploaded the revised version of the patch back in > August after some cleaning by Kurt, but have no way of confirming it. So > I've uploaded it again as guenther-20081204.patch. Thanks, patch looks good, committed to HEAD. Have you got a manpage update, by the way? -- -- 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#5843) Multi-master doesn't replicate deletes under certain circumstances.
by hyc＠symas.com 23 Jan '09

23 Jan '09

ildefonso_camargo(a)yahoo.com wrote: > Full_Name: Jose Ildefonso Camargo Tolosa > Version: 2.4.13 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (190.73.138.178) > > > Hi! > > I just configured multi-master replication (with N=3) for testing > purposes, and I just found an annoying problem, under these > conditions: > > 1. Configure a N number of "masters", and have them replicate happily > (this is important). > 2. Stop slapd service on all of the servers. > 3. Start slapd service on any number of servers< N (ie, leave at > least one stopped). > 4. Delete any entry (yes, it only fails with deletes, you can combine > changes: modify, add, and delete, and only deletes will fail to > replicate). > 5. Stop slapd service on *all of the servers again* (this is the most > important part). > 6. Start slapd service on all the servers. > 7. Look for the deleted entry on the server(s) that you left stopped in steps 3 > and 4, the entry is there!, but it isn't on the server(s) that were running in > step 3 and 4. > > You will see that, on the servers that you left down on step 3, the > deleted entries are still present. > > If you leave at least one server up, it replicates just fine, the > problem is when you stop all of the masters, and then start them again. > > If you need further info, just ask! I repeated the steps you described but was unable to reproduce the problem. However, following the steps that Adrien provided in a followup, I was able to reproduce the situation and identify the problem. A fix is now in CVS HEAD, please test. -- -- 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#5888) configure.in changes
by richton＠nbcs.rutgers.edu 23 Jan '09

23 Jan '09

Yeah, some "working" builds were affected. I just narrowed this down to these commits three minutes ago; I'll investigate and post back.

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2009