openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#5904) Docs: admin guide describes log levels inconsistently
by jclarke＠linagora.com 24 Jan '09

24 Jan '09

Full_Name: Jonathan Clarke Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch Submission from: (NULL) (62.147.206.193) The different log/debug levels available are described in three places in the admin guide: for olcLogLevel attribute in cn=config, for loglevel in slapd.conf and for -d command line option to slapd. Currently, each description offers different levels and different descriptions. In particular, only the first mentions the keywords (as well as integers). None mention the "None" level. I propose the patch below that offers similar information in all three places, an example clarifying the difference between loglevels "0" and "None" and clarification of the cn=config default. Most text is simply copied from the man pages. On a side note, the man pages have levels "cache" and "index" (4096 and 8192) commented out. The output from slapd -d? include them. Which should the admin guide reflect?

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 24 Jan '09

24 Jan '09

Andrew Bartlett wrote: > While I'm still confused about the ASN.1, I've coded to match OpenLDAP's > current behaviour. > > The deref overlay seems to be working well. Many thanks! Cool. I'd appreciate some definitive review of the correspondence of the implementation with respect to the draft (draft-masarati-ldap-deref in docs/draft, or from the IETF ID interface). That's the best I could put in place so far. 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#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 24 Jan '09

24 Jan '09

[please reply to the ITS, otherwise issues can't be tracked] Brett @Google wrote: > HI Ando, > > Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it > into RE24 in time for the 2.4.13 release ? apparently, yes. > If so, i can still see the behaviour here with 2.4.13, i can see operational > attributes, but non non-operational attributes, when mapping both > objectclass and attribute.. > > Bug seems to be focused on using of *, rather than an explicit list of > non-operational attrs which works, ie : > > I can search for attributes with * ( get all non-operational attributes ) > and don't get any non-operational attributes, whereas explicitly adding any > non-operational attribute will result i a search returning the named values, > which is allowable via the objectclass maps. > > seems to work the same (omitting non-oprational attrs), even if i dont > specufy the objectclass rwm maps. Not sure I understand. Can you post simple (both working and not working) examples? 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#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 24 Jan '09

24 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 24 Jan '09

24 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 24 Jan '09

24 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

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