openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#6766) memberOf does not replicate specially crafted modifications
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando If a modification deletes and recreates a member, something like dn: cn=group changetype: modify delete: member member: cn=user - add: member member: cn=user - the operation succeeds on the provider, but only the delete is replicated. This occurs because the operation, within the memberOf overlay, results in two separate operations: dn: cn=user changetype: modify delete: memberOf memberOf: cn=group dn: cn=user changetype: modify add: memberOf memberOf: cn=group with the same CSN, although corresponding to different operations, so the consumer ignores the second (btw, the CSN is the same of the modification that affects the "cn=group" entry). There may be two solutions: recognize that both operations affect the same entry, and group them, or change the CSN. p.

1 0

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

02 Jan '11

I've been doing some analysis of the Cyrus SASL code. When you say "we're using the parameters as documented by Cyrus", I presume the documentation you refer to is the comments within the source, in which case this all hinges on one line in include/sasl.h: * user_realm -- the user realm (may be NULL in case of client) (in the parameter list for the SASL_CB_CANON_USER callback). So what's meant by "the user realm"? When the callback is actually made (in lib/canonusr.c), the value passed is sconn->user_realm. This appears to be the value you get from sasl_getprop() with SASL_DEFUSERREALM. The user_realm value can be set in sasl_server_new (lib/server.c) and sasl_setprop (lib/common.c). There is a further description of realms in sasl/include.h: * IMPORTANT NOTE: server realms / username syntax * ... A single server may support multiple realms. If the * server knows the realm at connection creation time (e.g., a server * with multiple IP addresses tightly binds one address to a specific * realm) then that realm must be passed in the user_realm field of * the sasl_server_new call. If user_realm is non-empty and an * unqualified user name is supplied, then the canon_user facility is * expected to append "@" and user_realm to the user name. That is: it seems to me fairly clear that the purpose of user_realm is to provide a *default* realm which can be appended to the username when canonicalizing it. As a specific example, the code in _canonuser_internal() appends @<user_realm> if the username doesn't contain '@'. Furthermore, it's also clear from this that the username (SASL_USERNAME) is intended to include '@' and a realm; Cyrus is not designed to split it into a username part and a realm part. This matches what I see when using Cyrus SASL's standalone "sample-server" and "sample-client" programs, with GSSAPI and a client with a kerberos ticket from a different realm to the server: ... Negotiation complete Username: student(a)REALM3.WS.NSRC.ORG << sasl_getprop SASL_USERNAME Realm: (NULL) << sasl_getprop SASL_DEFUSERREALM SSF: 56 ... There's a full transcript of this example at http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2010-December/002177.html Next, looking at plugins/gssapi.c: AFAICS it doesn't make use of user_realm, but does ask GSSAPI if the name without realm is the same as the name with realm, and if so returns the name with the realm stripped off. /* If the id contains a realm get the identifier for the user without the realm and see if it's the same id (i.e. tmartin == tmartin(a)ANDREW.CMU.EDU. If this is the case we just want to return the id (i.e. just "tmartin" */ So, there is code in the GSSAPI plugin to *strip* the realm if it's the same as the default, but I don't think there's code to *separate* the username from the realm if the realm is foreign. Putting all this together: it seems to me that the "user_realm" you see is really just the configured default realm for the session; and that when you query SASL_USERNAME for a Kerberos client, you will see "username" if it's in the default realm, and "username(a)foreign.realm" for other realms. And this matches what I observe when testing this in OpenLDAP. As you suggested, I did bring this up on the cyrus-sasl mailing list (archive URL above), but no replies have been forthcoming so far. Now, if my understanding of the user_realm parameter is correct, I think there are two ways to make OpenLDAP's behaviour consistent with its documentation. (1) Stick more or less with the current behaviour, and change the documentation to say that you'll get uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth for foreign realms. However, the odd thing about the current behaviour is that setting olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into the auth DN, regardless of whether it's local or foreign. That's not very useful. I think it would make more sense, if olcSaslRealm is present, to use it to *qualify* usernames which don't have a realm. uid=kurt,cn=gssapi,cn=auth ---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth i.e. change the canonicalize function to append @user_realm if the username doesn't contain '@'. This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of stripping off the default realm. (2) Change the OpenLDAP behaviour so that it matches the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI To do this, the canonicalize function would have to parse the username, splitting it on '@' to separate username from realm, so that you would get uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth If the username doesn't contain '@', but olcSaslRealm is set, then I suggest you insert that instead: uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth And if there's no '@' and no olcSaslRealm, then just leave it alone: uid=kurt,cn=gssapi,cn=auth Regards, Brian.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

>> If yes, do I need to produce other infos related to my environment? > > Hi, I have fixed a couple of bugs in reqControls validation. However a > problem remains: the validator expects control values to consist in > hexadecimal digits (0-9, a-f), while your values in some cases aren't. > This could be related to interoperation issues between different slapd > versions, although I couldn't go back to the point where this change in > syntax occurred, if any. Spotted (and fixed) the bug in the enconding part of control values. It shouldnow be fixed. Please test and report. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Marco Pizzoli > Version: 2.4.23 > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > I had a problem with my Accesslog database. > I was investigating an anomaly that I had and, in doing this, I tried to: > - backup (slapcat) my accesslog db > - drop the entire db (rm -f alock, *.bdb, log.*, __db*) > - slapadd the db > > In slapadd I obtained this error: > > --- BEGIN > /usr/sbin/slapadd -b "cn=log,dc=mycorp.it" -l > /srv/bck/dump_db_log.ldif.20100916 > . 0.00% eta 08h35m elapsed spd 90.2 > k/s > str2entry: invalid value for attributeType reqControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=4907) > - 0.01% eta 05h58m elapsed spd 205.7 > k/s > Closing DB... > --- END > > I went to that line and found this entry: > > --- BEGIN > dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20100913065628.000008Z > reqEnd: 20100913065628.000009Z > reqType: search > reqSession: 1129 > reqAuthzID: > cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc=mycorp.it > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > "30440K0103043M7269643N > 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 > 330303030303023303033233030303030300001PP"} > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > reqDN: dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: TRUE > reqFilter: (objectclass=*) > reqAttr: 1.1 > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: 1 > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913065628Z > entryCSN: 20100913065628.167225Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.it > modifyTimestamp: 20100913065628Z > --- END > > Having produced this ldif using slapcat and not having "touched" the > environment > in between could I assume this to be a bug? > The entry showed is related to an access made by another OL server of my > deployment, which is in mirrormode(=true). > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26 > > > I deleted this entry and retried the import. > Now I have the following error: > --- BEGIN > /usr/sbin/slapadd2.4 -b "cn=log,dc=mycorp.it" -l > /tmp/dump_db_log.ldif.20100916_Corrected > " 4.69% eta 01h07m elapsed 03m19s spd 542.3 > k/s > str2entry: invalid value for attributeType reqRespControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=3099715) > * 4.70% eta 01h07m elapsed 03m20s spd 979.8 > k/s > Closing DB... > --- END > > The "corrupted" entry is this one: > > --- BEGIN > dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it > objectClass: auditBind > structuralObjectClass: auditBind > reqStart: 20100913093021.000000Z > reqEnd: 20100913093021.000001Z > reqType: bind > reqSession: 2746 > reqAuthzID: > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} > reqDN: uid=pe1597,ou=People,dc=mycorp.it > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913093021Z > entryCSN: 20100913093021.411398Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.it > modifyTimestamp: 20100913093021Z > --- END > > Is this a software bug? > > If yes, do I need to produce other infos related to my environment? Hi, I have fixed a couple of bugs in reqControls validation. However a problem remains: the validator expects control values to consist in hexadecimal digits (0-9, a-f), while your values in some cases aren't. This could be related to interoperation issues between different slapd versions, although I couldn't go back to the point where this change in syntax occurred, if any. p.

1 0

Re: (ITS#6749) Shut up "configure monitor database to enable"
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Please don't give the "configure monitor database to enable" message > by default. > > Either just remove it, or better, stop cn=config from adding a default > olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value > can still default to True if the attribute is absent.) Then you can > give the message if the _admin_ has explicitly asked for monitoring, > instead of if slapd has asked for it. I disagree; it is not cn=config that defaults database monitoring to TRUE; actually, it's back-bdb/back-hdb that sets its own monitoring to TRUE as soon as back-monitor support is compiled and the specific backend monitoring is successfully initilized. Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of LDAP_DEBUG_ANY. I understand that one could presume that the lack of database monitor in the configuration indicates that monitoring is not desired; this warning, however, tries to address a typical configuration error, when admins just forget to configure it. p.

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

> raphael.ouazana(a)linagora.com wrote: > >> When using memberOf overlay, a MODRDN request on a member does not >> update >> correctly the matching group, even if the memberof-refint option is set >> to >> true. >> >> In my little understanding, memberof_value_modify calls >> op->o_bd->be_modify >> which calls back the overlay code, and finally never reach the backend. > > Guess what, modrdn is the only operation test052 does not check :( > WOrking at it. Thanks, p. Fixed in HEAD; please test and report. Please note that test052 and the corresponding expected output data have been modified to check modrdn. p.

1 0

(ITS#6765) Server-side support of "Verify Credentials" extop
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando Added module in contrib/slapd-modules/vc/; no spec yet, simply mimicking the companion of what is currently implemented in libraries/libldap/vc.c. The current code should support SASL; untested yet, since the client does not implement SASL support yet. p.

1 0

(ITS#6764) ber_flatten() should return -1 on unmatched "{" "}"
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando also per <draft-ietf-ldapext-ldap-c-api>. p.

1 0

Re: (ITS#6758) Cleaning up SlapReply usage
by hyc＠symas.com 31 Dec '10

31 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Mostly done with the easily spotted cases. Hopefully HEAD's code > stayed valid through my commits. Need to think some more for the > rest. The decisions with greater chance of breaking things > remain, like ITS#6763. > > Other issues: > > * hyc, please have a look at slapd/bconfig.c 1.419. If I have > gotten things wrong, that one summarizes my mistakes nicely:-) I think you're over-paranoid. config_build_entry() is only called by internal plumbing and the SlapReply here never gets sent to send_ldap_result(). It's only passed in because be_add() expects one; the contents are mostly irrelevant. (Aside from rs_err) -- -- 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#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Mostly done with the easily spotted cases. Hopefully HEAD's code stayed valid through my commits. Need to think some more for the rest. The decisions with greater chance of breaking things remain, like ITS#6763. Other issues: * hyc, please have a look at slapd/bconfig.c 1.419. If I have gotten things wrong, that one summarizes my mistakes nicely:-) * If slap_send_ldap_result() or send_ldap_disconnect() see an entry with REP_ENTRY_MUST<RELEASE/BEFREED> and REP_SEARCH/SEARCHREF, should release/free the entry? That helps code which sends error without freeing sr_entry. It breaks if the entry comes from another Operation, or if the caller reuses a Search SlapReply for a non-Search and trusts rs->sr_un.sru_search to stay untouched. * Is the code getting clean enough that slap_send_search_entry's cleanup code can flush the entry independently of whether op->o_tag == LDAP_REQ_SEARCH? * slapi/slapi_pblock.c 1.81: /* TODO: Should REP_ENTRY_MODIFIABLE be set? */ I've no idea, and I've more pressing things to look at... Notes on the updates: * "Reset some SlapReply flags & data" commits vs "avoid SlapReply reuse" commits: The combination might be redundant/overcautious, but tries to catch problems from remaining unclean code from both ends. * result.c, freeing as well as releasing entries as soon as possible: More readable, and since the entry isn't needed: The sooner we get rid of it, the less chance for an entry leak. * commits "Use rs_*() to manage SlapReply entries." Switching to rs_flush_entry(): - result.c:slap_send_search_entry(), overlays/pcache.c, overlays/translucent.c, slapi/slapi_pblock.c: These did not clear the MODIFIABLE flag along with MUSTBEFREED. Switching to use rs_ensure_entry_modifiable(): - syncprov_operational(), overlay collect: noop change (except operational should not update the entry) - overlay valsort: It needlessly required REP_ENTRY_MUSTBEFREED as well as MODIFIABLE. But the entry can also be MODIFIABLE and e.g. on the stack. - contrib overlays cloak, usn: Had entry leaks. -- Hallvard

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