openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#6785) slapo-chain mishandles sr_text/sr_matched
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard ldap_chain_response() can send sr_text/sr_matched which refers to a different error than sr_err and rc. It saves rs-> sr_err, sr_text, sr_matched to three local variables and can restore them later, but not maintain the text and matched variables in parallel with err. Also it does not track/reset/obey REP_MATCHED_MUSTBEFREED along with sr_matched. Fails test032-chain with the asserts below. However there may be non-success result with the wrong text/matched too, that cannot be assert()ed. Come to think of it, maybe the last issues applies to ITS#6774 too? REP_MATCHED_MUSTBEFREED, mismatch between failure code and text/matched. Index: servers/slapd/back-ldap/chain.c @@ -1019,4 +1019,14 @@ ldap_chain_response( Operation *op, SlapReply *rs ) rs->sr_ref = NULL; + const char *bad_incoming_matched = NULL, *bad_incoming_text = NULL; + switch ( sr_err ) { + case LDAP_SUCCESS: + case LDAP_COMPARE_TRUE: + case LDAP_COMPARE_FALSE: + bad_incoming_matched = matched; + case LDAP_REFERRAL: + bad_incoming_text = text; + } + /* we need this to know if back-ldap returned any result */ lb.lb_lc = lc; @@ -1169,4 +1179,15 @@ cannot_chain:; dont_chain:; + switch ( sr_err ) { + case LDAP_SUCCESS: + case LDAP_COMPARE_TRUE: + case LDAP_COMPARE_FALSE: + assert( !matched || bad_incoming_matched ); + case LDAP_REFERRAL: + assert( !text || bad_incoming_text ); + } + assert( rc != LDAP_SUCCESS || + (( !text || bad_incoming_text) && + ( !matched || bad_incoming_matched ))); rs->sr_err = sr_err; rs->sr_type = sr_type;

1 0

(ITS#6784) Spurious mutex unlock in authzid.c
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard authzid_conn_find() in contrib/slapd-modules/authzid/authzid.c can do ldap_pvt_thread_mutex_unlock( &authzid_mutex ); even though every code path from ldap_pvt_thread_mutex_lock( &authzid_mutex ); elsewhere in authzid.c leads to an unlock statement of its own.

1 0

(ITS#6783) back-monitor cache/mutex problem
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard Core dump in back-monitor with LDAP_THREAD_DEBUG when I hit ^C: ASSERT_OWNER( mutex, "ldap_pvt_thread_mutex_unlock" ); #2 ldap_pvt_thread_mutex_unlock (mutex=0x1a526c0) at thr_debug.c:1031 #3 monitor_cache_release (mi=0x92c8c0, e=0x19ec7f8) at cache.c:389 #4 monitor_send_children (op=0x236bcb0, rs=0x7f54ce4eea40, e_parent=0x19ec758, sub=1) at search.c:97 #5 monitor_back_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:245 #6 fe_op_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:372 That's the o_abandon branch in monitor_send_children(). I copied the loop out of the o_abandon branch. test036 crashed with what I assume is the same problem. No need to hit ^C at the right time: Index: back-monitor/search.c @@ -89,2 +89,9 @@ monitor_send_children( + if ( nonvolatile == 0 && (e_tmp = e) != NULL ) { + do { + mp = e_tmp->e_private; + LDAP_PVT_THREAD_ASSERT_MUTEX_OWNER( &mp->mp_mutex ); + } while ( (e_tmp = mp->mp_next) && e_tmp != e_nonvolatile ); + } + if ( op->o_abandon ) { There is a similar loop further down, I didn't look at that one. Variables at the crash: e == e_nonvolatile e_tmp == ((monitor_entry_t *) e->e_private)->mp_next *(monitor_entry_t *) e->e_private == { mp_mutex = {...}, mp_next = 0x261b2a8, mp_children = 0x261b668, mp_info = 0x8f21c0, mp_flags = 32, mp_cb = 0x0 } *(monitor_entry_t *) e_tmp->e_private == { mp_mutex = {...}, mp_next = 0x261b2f8, mp_children = 0x261ba28, mp_info = 0x8f2258, mp_flags = 128, mp_cb = 0x0 }

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com 11 Jan '11

11 Jan '11

Hallvard B Furuseth wrote: > Reopening this ITS... > > Howard Chu writes: >>> Full_Name: Hallvard B Furuseth >>> >>> overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. >>> findcsn_cb() says >>> /* We just want to know that at least one exists, so it's OK if >>> * we exceed the unchecked limit or size limit. >>> */ >>> >>> This looks like it can return a false positive if two or more other >>> entries which the filter would eliminate have the same hash as the >>> value syncprov searches for. >> >> I don't believe this can cause any problem though. CSN indexing doesn't use a >> hash the way other indices do; the CSN timestamp is converted to binary form >> and saved as a 40 bit integer. Index collisions will only occur for multiple >> changes that occurred within the same 1-second interval. > > Only if entryCSN is indexed, which is recommended but not required in > man slapo-syncprov. With un-indexed entryCSN it'll hit the unchecked > limit if there are two or more entries in scope for the search. > > Also - another marginal case - findcsn_cb() assumes adminLimitExceeded > implies a size limit (.size or .unchecked). It could also mean a hard > time limit. After someone did ^Z on slapd while stepping through some > debugging, if nothing else. Wrong. AdminLimitExceeded ONLY means unchecked here. Otherwise it would be SizeLimitExceeded (or TimeLimitExceeded). -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 11 Jan '11

11 Jan '11

Reopening this ITS... Howard Chu writes: >> Full_Name: Hallvard B Furuseth >> >> overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. >> findcsn_cb() says >> /* We just want to know that at least one exists, so it's OK if >> * we exceed the unchecked limit or size limit. >> */ >> >> This looks like it can return a false positive if two or more other >> entries which the filter would eliminate have the same hash as the >> value syncprov searches for. > > I don't believe this can cause any problem though. CSN indexing doesn't use a > hash the way other indices do; the CSN timestamp is converted to binary form > and saved as a 40 bit integer. Index collisions will only occur for multiple > changes that occurred within the same 1-second interval. Only if entryCSN is indexed, which is recommended but not required in man slapo-syncprov. With un-indexed entryCSN it'll hit the unchecked limit if there are two or more entries in scope for the search. Also - another marginal case - findcsn_cb() assumes adminLimitExceeded implies a size limit (.size or .unchecked). It could also mean a hard time limit. After someone did ^Z on slapd while stepping through some debugging, if nothing else. -- Hallvard

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 10 Jan '11

10 Jan '11

On Mon, Jan 10, 2011 at 11:48:37AM -0800, Howard Chu wrote: > >No problem. I propose the following to bring the docs in line with > >behaviour. > > This looks a bit too specific, the olcSaslRealm setting affects > other SASL mechanisms too. True, although this text is under the GSSAPI subheading so I would read it as specific to the GSSAPI mechanism. > For GSSAPI it should probably just say > not to specify olcSaslRealm at all since the mechanism has its own > notion of realms already. If they are using a mixture of SASL mechanisms then they might need to set olcSaslRealm for the benefit of another one. How about this: ------------------------------------------------------------------- If you are using only GSSAPI authentication then you should not configure olcSaslRealm. If you do, then it is always inserted as an extra component in the authorization DN, regardless of the realm of the client. For example, if you set olcSaslRealm to {{EX:example.com}} then you will get: uid=kurt,cn=example.com,cn=gssapi,cn=auth uid=ursula/admin(a)foreign.realm,cn=example.com,cn=gssapi,cn=auth -------------------------------------------------------------------

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by hyc＠symas.com 10 Jan '11

10 Jan '11

Brian Candler wrote: > On Sun, Jan 02, 2011 at 07:40:25PM -0800, Howard Chu wrote: >> I don't believe we have any freedom to make any code changes here; >> feel free to suggest verbiage changes for the documentation. > > No problem. I propose the following to bring the docs in line with > behaviour. This looks a bit too specific, the olcSaslRealm setting affects other SASL mechanisms too. For GSSAPI it should probably just say not to specify olcSaslRealm at all since the mechanism has its own notion of realms already. Most likely you would only set this for something like DIGEST-MD5 which uses realms but doesn't inherently know its own realm name. > --- sasl.sdf.orig 2011-01-03 09:45:55.754879001 +0000 > +++ sasl.sdf 2011-01-03 10:07:34.808208000 +0000 > @@ -135,25 +135,35 @@ > For the purposes of authentication and authorization, {{slapd}}(8) > associates an authentication request DN of the form: > > -> uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth > +> uid=<primary[/instance][@realm]>,cn=gssapi,cn=auth > + > +The realm is omitted by Cyrus SASL if it's equal to the default realm of the > +server in {{FILE:/etc/krb5.conf}}. > > Continuing our example, a user with the Kerberos principal > {{EX:kurt@EXAMPLE.COM}} would have the associated DN: > > -> uid=kurt,cn=example.com,cn=gssapi,cn=auth > +> uid=kurt,cn=gssapi,cn=auth > > and the principal {{EX:ursula/admin@FOREIGN.REALM}} would have the > associated DN: > > -> uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > +> uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > > > -The authentication request DN can be used directly ACLs and > +The authentication request DN can be used directly in ACLs and > {{EX:groupOfNames}} "member" attributes, since it is of legitimate > LDAP DN format. Or alternatively, the authentication DN could be > mapped before use. See the section {{SECT:Mapping Authentication > Identities}} for details. > > +If you configure olcSaslRealm then it is always inserted as an extra > +component in the authorization DN, regardless of the realm of the client. > +For example, if you set olcSaslRealm to {{EX:example.com}} then you will > +get: > + > +> uid=kurt,cn=example.com,cn=gssapi,cn=auth > +> uid=ursula/admin(a)foreign.realm,cn=example.com,cn=gssapi,cn=auth > > H3: KERBEROS_V4 > > -- -- 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#5350) Request: ITS links in mailinglist archives
by h.b.furuseth＠usit.uio.no 10 Jan '11

10 Jan '11

Kurt Zeilenga writes: > However, there may be an reasonable alternative suggestion. The ITS > software itself could be modified to include a URI to the issue in > each message it sends. This would not only show up in archives, but > in mail distributed to -bugs list and directly to users of the system. Yes, that would help. Won't affect the discussion lists, though. Except maybe people will start to quote the URLs more. -- Hallvard

1 0

Re: (ITS#6684)
by hyc＠symas.com 09 Jan '11

09 Jan '11

Norbert Püschel wrote: > Am 30.12.10 18:28, schrieb Howard Chu: >> norbert(a)pueschel.net wrote: >>> Updated TAR-file with (hopefully) sufficient copyright notice... >>> >>> http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar >> >> Your code does a string compare againset "memberOf" to detect those >> filter references. >> 1) it should simply be comparing the AttributeDescription pointers >> 2) since the "memberof" attribute is actually configurable in the >> memberof overlay, there's no guarantee that this is the correct >> attribute to be looking for. It should also be configurable in your >> patch. >> > You are right, of course. The problem is, I do not understand enough of > internal structures to find the correct pointer... I would need to > detect the memberof-overlay and find the correct string or pointer to > compare to. I will gladly do so if you can give me some hints where to look. AttributeDescriptions are a fundamental data structure used throughout the code. It would be impossible to have read any of the existing overlay code without encountering countless examples of their use. There is no need to detect the memberof overlay. All you need to do is provide a configuration option to specify the attribute you are going to treat as a memberof attribute. >> You're using strcasecmp, but your inputs are already normalized >> values. You should just use ber_bvcmp. >> > Right, see above. > >> Replying to the original: >> >>> 1) Using non-DN-valued URIs for autogroup does not work correctly, even >>> with the latest version from HEAD. Especially changing group member is >>> not tracked. >> >> I don't see why this should ever work or be supported. LDAP groups >> list DNs. >> > > Wrong. If you really think so, why did you accept Raphael Ouazana's > patch, which is all about making this case work? > Also see below. >>> 2) Using the memberOf-overlay for constructing autogroups does not work >> >> I don't see any reason why this should work. The memberof overlay is >> not used to construct groups, it is only used to report on group >> memberships that have already been defined. > Well, consider the following construction (which I am using in our ldap > directory and which is the reason I started work on the autogroup overlay): Ugh. > dn: cn=admins,ou=access,dc=networker-gmbh,dc=de > objectClass: groupOfNames > cn: admins > member: uid=xxxxx,ou=people,dc=networker-gmbh,dc=de > member: uid=yyyyyy,ou=people,dc=networker-gmbh,dc=de > > dn: cn=admins(a)networker-gmbh.de,ou=aliases,dc=networker-gmbh,dc=de > objectClass: nisMailAlias > objectClass: labeledURIObject > cn: admins(a)networker-gmbh.de > labeledURI: > ldap:///ou=people,dc=networker-gmbh,dc=de?mail?one?(&(objectClass=inetOrgPerson)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) > > dn: cn=admins,ou=groups,dc=networker-gmbh,dc=de > objectClass: posixGroup > objectClass: labeledURIObject > cn: admins > gidNumber: 10100 > labeledURI: > ldap:///ou=people,dc=networker-gmbh,dc=de?uid?one?(&(objectClass=posixAccount)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) > > Additionally, consider this relevant excerpt from slapd.conf: > > overlay dynlist > dynlist-attrset groupOfNames labeledURI member > dynlist-attrset nisMailAlias labeledURI rfc822MailMember:mail > > overlay autogroup > autogroup-attrset posixGroup labeledURI memberUid > > As you can see, I use memberOf the construct mail aliases and posix > group memberships from a groupOfNames master-list. For the mail aliases, > dyngroup is sufficient, but the posix groups also need reverse lookups, > which is why I'm using the autogroup overlay for this. Also, I cannot > use a dn-valued list for the posix groups, as the Solaris NSS-libraries > require the uid attribute to not contain a full dn. Short answer - use an NSS client that actually supports RFC2307bis, like every other vendor in the world already does. In the meantime, if you submit a cleaned up patch that makes better use of the slapd APIs, we can review it again. -- -- 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#5350) Request: ITS links in mailinglist archives
by Kurt Zeilenga 07 Jan '11

07 Jan '11

In short, no. The underlying archives are the email messages submitted to the list stored in mbox format, which are then reformatted to HTML using off-the-shelf software. While it technically possible to hack that software to do all kinds of reformatting (as we have the source), we don't have the resources to maintain a custom fork of that software. However, there may be an reasonable alternative suggestion. The ITS software itself could be modified to include a URI to the issue in each message it sends. This would not only show up in archives, but in mail distributed to -bugs list and directly to users of the system.

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