openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by sgallagh＠redhat.com 26 Jan '11

26 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to reopen the discussion on this issue. We're hitting this same problem with the SSSD when dealing with ActiveDirectory. It really doesn't make sense to me that every consumer of the OpenLDAP libraries should be required to reimplement this (admittedly incorrect) extension to ActiveDirectory. As Petter suggested in his comment from April 21, 2008, ActiveDirectory provides a server control to identify that the feature is in play. I feel that it would be beneficial to OpenLDAP's library consumers if they handled range lookups automatically and internally, similar to the way that referrals are chased. Consumers of the OpenLDAP API should be able to reliably assume that if they ask for the set of values for an attribute of a completed request, that they will get back all of the values. Please reconsider adding this support into OpenLDAP. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AQQgACgkQeiVVYja6o6OACwCgg4t5Mm54X+ohYzhvG9fRBMTb gO4An0j/152a0PHFMTxTIuQ6kamlcsFb =3a3m -----END PGP SIGNATURE-----

1 0

Re: (ITS#6752) slapo-dynlist issues
by h.b.furuseth＠usit.uio.no 25 Jan '11

25 Jan '11

Charles Owens writes: > Would you characterize this as being a fix for stability, performance, > or some of both? Both, plus code cleanup with no user-visible effect. HEAD dynlist.c rev 1.72 = performance & cleanup, 1.73-1.74 = fixes, 1.75 = cleanup. If you're cherry-picking recent changes, you might as well grab the fix 1.76 for ITS#6758 as well. -- Hallvard

1 0

Re: (ITS#6803) LDAP Server
by quanah＠zimbra.com 24 Jan '11

24 Jan '11

--On Sunday, January 23, 2011 12:09 PM +0000 kashif.hameed(a)vopium.com wrote: > Full_Name: Kashif Hameed > Version: 2.3.8 > OS: centos5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.215.176.22) > > > I am installing and configuring ldap server with authentication samba but > i am unable to do this because with samba authentication it will return > error > > /usr/sbin/smbldap-passwd: user root doesn't exist > > so could any one help me regarding this issue The OpenLDAP project is not the Samba project. Samba questions should be directed to the Samba project. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6804) 'self' access modifier only works for first entry
by djpohly＠gmail.com 23 Jan '11

23 Jan '11

Full_Name: Devin J. Pohly Version: 2.4.23 OS: Linux URL: http://openldap.pastebin.com/gvswpxLX Submission from: (NULL) (98.235.33.55) Description: I have set up an LDAP directory which contains users and flat groups (groupOfNames/member style). I want to use the access controls to only allow users to see their own groups and membership, so I defined the following controls: access to dn.onelevel="ou=group,o=org" attrs=entry by dnattr=member read access to dn.onelevel="ou=group,o=org" attrs=member by dnattr=member selfread Steps to reproduce: 1. Start a new instance of OpenLDAP with the slapd.conf file provided at <http://openldap.pastebin.com/gvswpxLX> and an empty database. 2. Get grouptest.ldif from <http://openldap.pastebin.com/X1DUyGmf> and add it to the directory: ldapadd -x -H $LDAPURI -D uid=admin,o=org -w admin -f grouptest.ldif This creates two users, foo and bar, and two groups, g1 and g2. Each user is in both groups. 3. Compare the outputs of: ldapsearch -x -H $LDAPURI -D uid=foo,ou=user,o=org -w foo -b ou=group,o=org ldapsearch -x -H $LDAPURI -D uid=bar,ou=user,o=org -w bar -b ou=group,o=org Expected results: Foo's query shows "member: foo" for both g1 and g2. Bar's query shows "member: bar" for both g1 and g2. Actual results: Foo's query shows "member: foo" for both g1 and g2. Bar's query does not show any member attributes. Note: Changing the order in which the users are listed changes the behavior; only the first user listed matches 'self'. Changing the 'selfread' privilege to 'read' behaves correctly: both queries display both users' memberships in the groups. So the problem lies somewhere in the way the 'self' modifier is implemented.

1 0

(ITS#6803) LDAP Server
by kashif.hameed＠vopium.com 23 Jan '11

23 Jan '11

Full_Name: Kashif Hameed Version: 2.3.8 OS: centos5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.215.176.22) I am installing and configuring ldap server with authentication samba but i am unable to do this because with samba authentication it will return error /usr/sbin/smbldap-passwd: user root doesn't exist so could any one help me regarding this issue Thanks

1 0

Re: (ITS#6794) slapadd -q problems on glued databases
by Ralf Haferkamp 21 Jan '11

21 Jan '11

I just committed a fix and a testcase (to the regression directory) for this to HEAD. Please test.

1 0

(ITS#6802) Patch - Mozilla NSS - restart modules before NSS_Init after a fork()
by rmeggins＠redhat.com 21 Jan '11

21 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-secmod-restartmodules-20110… Submission from: (NULL) (76.113.111.209) NSS enforces the pkcs11 requirement that modules should be unloaded after a fork() - since there is no portable way to determine if NSS has been already initialized in a parent process, we just call SECMOD_RestartModules with force == FALSE before doing any NSS initialize calls - if the module has been unloaded due to a fork, it will be reloaded, otherwise, it is a no-op. These patch files are 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, Rich Megginson 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.

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by hyc＠symas.com 20 Jan '11

20 Jan '11

ondrej.kuznik(a)acision.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/09/2010 03:50 PM, ondrej.kuznik(a)acision.com wrote: >> I have put a preliminary version of patches that modify the unique >> overlay here >> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz >> >> They add a new configuration attribute olcUniqueAllowManageBypass (it is >> prohibitively long for a name, though) that, if set to TRUE, triggers >> the uniqueness checks not to be performed if the operation has manage >> privilegies on the entry. There are three separate patches, >> configuration code regarding the new attribute, the checks in >> unique_{add,modify,modrdn} and manpage modifications. >> > After a conversation with Howard, I have modified the patches so that > the overlay check for the ManageDsaIt control instead. That control > should be set for each operation coming from replication. The patches > are here: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101202-unique_bypass_v2.tgz > > Is there anything else that comes to mind? I'm not sure it merits a config keyword. We already have instances where administrators are implicitly allowed to bypass rules that restrict normal users, and replication is obviously a system-level operation, not user level. -- -- 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#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 20 Jan '11

20 Jan '11

Chris Mikkelson wrote: > On Thu, Jan 13, 2011 at 12:30:32PM -0800, Howard Chu wrote: >> cmikk(a)qwest.net wrote: >>> Other than the patch I suggested (using the list head's >>> CSN value directly), I can think of two other approaches: >>> >>> 1) When adding an entry to the sessionlog, check >>> if sl_mincsn is empty. If it is, update sl_mincsn >>> to the new entry's CSN. >>> >>> 2) When initializing the sessionlog, set sl_mincsn >>> to the maximum contextCSN value of the underlying >>> database. >>> >>> #2 seems ideal from an efficiency standpoint, although it >>> differs from the algorithm the current code appears to be >>> intended to implement. >> >> We should have gone with #2. The problem scenario: > > The current code (in HEAD) covers the vast majority of > cases, but still has a hole which can come up quite often > in MMR + refreshOnly scenarios. The scenario: > > 1: provider 1, provider 2, and consumer all in sync. SID 1 CSN > is a few minutes old, SID 2 is a few hours old. Both sessionlogs > are empty with sl_mincsn set to the newest (provider 1) CSN value > 2: stop consumer > 3: write on provider 2 > 4: start consumer > > The provider will see that the consumer is out of date > wrt the SID 2 CSN and that the old value of the SID 2 CSN > predates sl_mincsn, so it will skip the session log. > > I think the following approach will cover this case: > > * sl_mincsn holds a CSN value for each SID Yeah, looks like we were headed there anyway. > * in syncprov_op_search, mincsn is compared to > the sl_mincsn value with the same SID The mincsn variable is no longer useful as-is. We need to compare the vector of CSNs from the cookie with the vector of CSNs in the provider. If any CSN in the consumer is older than the matching sl_mincsn then the log must be skipped. At this point there are a bunch of redundant O(N^2) walkthrus of the CSNs anyway, so getting rid of mincsn would be a good simplification. Since there may be many SIDs it would be better to sort both vectors and then walk thru them sequentially. > * when expiring log entries in in syncprov_add_slog, > the sl_mincsn value with the same SID as the expired > entry's CSN is set to the maximum of the two values. Yes. > If there is no matching SID in sl_mincsn, then: > > * in syncprov_op_search, this implies that the > mincsn's SID has been added to the provider's > configuration since startup or that the first > change recorded by that SID occurred since startup, > and thus the sessionlog contains sufficient > information > > * in syncprov_add_slog, sl_mincsn will need to > be expanded to hold the new SID's CSN > > Thoughts? Sounds right. -- -- 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#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 20 Jan '11

20 Jan '11

On Thu, Jan 13, 2011 at 12:30:32PM -0800, Howard Chu wrote: > cmikk(a)qwest.net wrote: > >Other than the patch I suggested (using the list head's > >CSN value directly), I can think of two other approaches: > > > > 1) When adding an entry to the sessionlog, check > > if sl_mincsn is empty. If it is, update sl_mincsn > > to the new entry's CSN. > > > > 2) When initializing the sessionlog, set sl_mincsn > > to the maximum contextCSN value of the underlying > > database. > > > >#2 seems ideal from an efficiency standpoint, although it > >differs from the algorithm the current code appears to be > >intended to implement. > > We should have gone with #2. The problem scenario: The current code (in HEAD) covers the vast majority of cases, but still has a hole which can come up quite often in MMR + refreshOnly scenarios. The scenario: 1: provider 1, provider 2, and consumer all in sync. SID 1 CSN is a few minutes old, SID 2 is a few hours old. Both sessionlogs are empty with sl_mincsn set to the newest (provider 1) CSN value 2: stop consumer 3: write on provider 2 4: start consumer The provider will see that the consumer is out of date wrt the SID 2 CSN and that the old value of the SID 2 CSN predates sl_mincsn, so it will skip the session log. I think the following approach will cover this case: * sl_mincsn holds a CSN value for each SID * in syncprov_op_search, mincsn is compared to the sl_mincsn value with the same SID * when expiring log entries in in syncprov_add_slog, the sl_mincsn value with the same SID as the expired entry's CSN is set to the maximum of the two values. If there is no matching SID in sl_mincsn, then: * in syncprov_op_search, this implies that the mincsn's SID has been added to the provider's configuration since startup or that the first change recorded by that SID occurred since startup, and thus the sessionlog contains sufficient information * in syncprov_add_slog, sl_mincsn will need to be expanded to hold the new SID's CSN Thoughts? -- Chris Mikkelson | It was mentioned on CNN that the prime number cmikk(a)qwest.net | discovered recently is four times bigger than the previous record. -- unknown

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
18
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 2011