openldap-bugs July 2009

openldap-bugs@openldap.org

49 participants
166 discussions

Re: (ITS#6197) ldap_err2string()/ldap_perror() strangeness
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

Also ldap_err2string(), unlike ldap_perror(), does not pass messages from recognized result codes through _() - i.e. the optional gettext(). I'll fix that too. -- Hallvard

1 0

Re: (ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

hyc(a)symas.com writes: > This code has changed in HEAD. Closing this ITS. Hm? The unlock-lock is still there. If it still needs to let through another thread to c_write1_mutex I don't see how the connection_valid() test in front of it helps. -- Hallvard

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 07 Jul '09

07 Jul '09

On Mon, Jul 6, 2009 at 9:32 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wro= te: > > --On Monday, July 06, 2009 6:07 PM +0000 jorge.perez(a)adaptia.net wrote: > >> >> With the debug symbols there's an assert that fails in slapd_clr_write >> method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): > > Thanks. =C2=A0The hang should really be fixed now. :P =C2=A0Please re-syn= c RE24 and test again. =C2=A0Thank you! Hello, The problem still reproduces. Threads hung on the same ptread_cond_wait.call. This time the assert has not failed. Thread 18 (Thread 1390426432 (LWP 17780)): ---Type <return> to continue, or q <return> to quit--- #0=C2=A0 0x00002b5a8515b1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1=C2=A0 0x00000000004525a4 in send_ldap_ber (op=3D<value optimized out>, ber=3D0x52e01150) at result.c:156 #2=C2=A0 0x000000000045449e in slap_send_search_entry (op=3D0x2b5a849138f4, rs=3D0x52e02da0) at result.c:1259 Regards

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by jsafrane＠redhat.com 07 Jul '09

07 Jul '09

On 02/10/2009 09:53 AM, hyc(a)symas.com wrote: > I opted for this approach, now checked into HEAD. Please test. After few months in production it seems the bug is gone. Thanks a lot for the fix! Jan

1 0

Re: (ITS#6198) Authorization for extensions
by hyc＠symas.com 07 Jul '09

07 Jul '09

Michael Ströder wrote: > Howard Chu wrote: >> Ugh, no. There's no way any sysadmin is going to remember what each OID >> means. > > There are tools to display them: > http://demo.web2ldap.de:1760/web2ldap?ldap://ldap.uninett.no/??base > > There also could be GUI tools to display ACLs to humans. None of which may be accessible when trying to diagnose a crashed system. It must always be practical to manually edit a slapd configuration. >> Each exop will be given a "friendly name" like WhoAmI, ModifyPwd, >> etc. > Who maintains the list of friendly names? Yes, the OpenLDAP project can > maintain a proprietary list like all other LDAP vendors do. :-( > Probably that's another topic for cross-vendor coordination... Interoperability is not a requirement for slapd configuration elements. However, any shortname already present in RFCs would be obvious first choices. E.g., "passwdModify" (RFC 3062, section 2) and "whoami" (RFC4532, section 2) (derived by dropping the letters "OID" from the name of the OID definition). Or just accept any oidmacros, as some of the other config items already do. On that score I believe we should promote more pervasive use OID macros instead of numeric OIDs, because that greatly enhances comprehension by human administrators. I believe we should define macros for all of the syntaxes etc. already in common use in slapd and document them, guaranteeing that they will be available for everyone else who uses OpenLDAP to also take advantage of them. (Note that back-config already has several hardcoded, but they're decorated with "OM" prefix and not documented for public consumption. For real use they should be unadorned, using plain names such as "integer" or "directoryString" ...) -- -- 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#6198) Authorization for extensions
by michael＠stroeder.com 07 Jul '09

07 Jul '09

Howard Chu wrote: > Michael Ströder wrote: >> hyc(a)OpenLDAP.org wrote: >>> Full_Name: Howard Chu >>> Version: HEAD/2.5 >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (76.91.220.157) >>> Submitted by: hyc >>> >>> >>> The access control mechanism needs to be extended to control actions, >>> not just >>> objects, to control who may use various LDAP Controls and Extended >>> Operations. >> >> +1 >> >>> E.g. >>> access to control=<oid> by<who> >>> access to op=<operation or oid> by<who> >> ^^^^^^^^^ >> What is "operation" supposed to be? I'd prefer only to allow "oid" since >> OIDs are the only identifiers clearly specified in RFCs and I-Ds. > > Ugh, no. There's no way any sysadmin is going to remember what each OID > means. There are tools to display them: http://demo.web2ldap.de:1760/web2ldap?ldap://ldap.uninett.no/??base There also could be GUI tools to display ACLs to humans. > Each exop will be given a "friendly name" like WhoAmI, ModifyPwd, > etc. Who maintains the list of friendly names? Yes, the OpenLDAP project can maintain a proprietary list like all other LDAP vendors do. :-( Probably that's another topic for cross-vendor coordination... Ciao, Michael.

1 0

Re: (ITS#6198) Authorization for extensions
by hyc＠symas.com 07 Jul '09

07 Jul '09

Michael Ströder wrote: > hyc(a)OpenLDAP.org wrote: >> Full_Name: Howard Chu >> Version: HEAD/2.5 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc >> >> >> The access control mechanism needs to be extended to control actions, not just >> objects, to control who may use various LDAP Controls and Extended Operations. > > +1 > >> E.g. >> access to control=<oid> by<who> >> access to op=<operation or oid> by<who> > ^^^^^^^^^ > What is "operation" supposed to be? I'd prefer only to allow "oid" since > OIDs are the only identifiers clearly specified in RFCs and I-Ds. Ugh, no. There's no way any sysadmin is going to remember what each OID means. Each exop will be given a "friendly name" like WhoAmI, ModifyPwd, etc. Don't make the same mistake the original LDAP implementers did - numeric OIDs are for machine consumption only; they should always be mapped to mnemonic names for use by humans. (Technically they should be mapped to *localized* names; obviously the names were not intended to be part of the protocol specification. This is another glaring flaw in the LDAP specifications...) -- -- 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#6198) Authorization for extensions
by michael＠stroeder.com 07 Jul '09

07 Jul '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/2.5 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > The access control mechanism needs to be extended to control actions, not just > objects, to control who may use various LDAP Controls and Extended Operations. +1 > E.g. > access to control=<oid> by <who> > access to op=<operation or oid> by <who> ^^^^^^^^^ What is "operation" supposed to be? I'd prefer only to allow "oid" since OIDs are the only identifiers clearly specified in RFCs and I-Ds. Ciao, Michael.

1 0

(ITS#6198) Authorization for extensions
by hyc＠OpenLDAP.org 06 Jul '09

06 Jul '09

Full_Name: Howard Chu Version: HEAD/2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc The access control mechanism needs to be extended to control actions, not just objects, to control who may use various LDAP Controls and Extended Operations. E.g. access to control=<oid> by <who> access to op=<operation or oid> by <who> Perhaps the control= / op= specifier should be usable in combination with the other <what> specifiers; I haven't thought too deeply about it. It only makes sense in limited contexts, since various extensions may not even affect any particular directory object.

1 0

Re: (ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by hyc＠symas.com 06 Jul '09

06 Jul '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > send_ldap_ber() has a suspicious-looking waitloop doing this: > > if ( ldap_pvt_thread_mutex_trylock(&conn->c_mutex )) { > ldap_pvt_thread_mutex_unlock(&conn->c_write1_mutex ); > ldap_pvt_thread_mutex_lock(&conn->c_write1_mutex ); > > Unlock does not mean a thread waiting for c_write1_mutex will acquire > it immediately. Such a thread may have to wait until it is scheduled, > at which time the looping thread has locked the mutex again. This code has changed in HEAD. Closing this ITS. > > On the Linux box on my desk, a pure unlock-lock loop goes through > 50000-100000 iterations before another thread waiting for the lock > acquires it. OTOH, on a heavily used box it takes ~50 iterations. > > A sched_yield() between the unlock and lock reduces #iterations to 1. > No idea if that is the right solution, nor how serious the problem is. > > The lock/unlock statements themselves are from result.c rev 1.323, > but then with some more locking between them which disappeared in > later revisions. > > My lock-unlock test program: > > #include<pthread.h> > #include<sched.h> > #include<stdio.h> > #include<stdlib.h> > #include<sys/select.h> > > static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; > static unsigned count; > > static void *waiter(void *arg) { > pthread_mutex_lock(&m); > printf("Locked after %u iterations.\n", count); > exit(0); > } > > int main() { > pthread_t t; > pthread_mutex_lock(&m); > pthread_create(&t, NULL, waiter, NULL); > select(0, NULL, NULL, NULL,&(struct timeval){0, 100000}); > for (count = 1 ;; ++count) { > pthread_mutex_unlock(&m); > pthread_mutex_lock(&m); > } > } > > -- -- 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

← Newer
1
...
10
11
12
13
14
15
16
17
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 July 2009