- openldap-bugs - openldap.org

Re: ITS#6475
by manu＠netbsd.org 14 Mar '10

14 Mar '10

<masarati(a)aero.polimi.it> wrote: > > access to * attrs=cmusaslsecretOTP > > by dn.regex="cn=replica,o=test" write stop > > by * break > > This is orthogonal to the sasl auxprops discussion. It's a matter of > well-configuring the authorizing identity in slapo-chain(5). I pointed it here for future reference because this is an unusual case. I suspect everyone configure replicas with universal read-only access. For this to work, replica must also have write access to cmusaslsecretOTP. > > Another point: bind on the replica is impossible when the master is > > down. I understand this is to prevent replaying the same OTP on multiple > > replicas, but that defeats the purpose of setting up replicas for fail > > over. > > This was clearly pointed out at the beginning of the discussion. You > can't have both, it should be clear. Yes, I understand that. > Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is > used, OTP breaks. If it is acceptable to have it broken, we can remove > the hardcoding, and let admins decide whether they prefer fail-over over > consistency. I'd have no doubt, and favor consistency. When you tell about using the shadow copy, the modification will still be sent to the master, right? Such a behavior allows replays attacks within the modification propagation time frame, but it ensures that bind are still possible when then master is down. I think it could be interesting to have a configuration setting for that. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 14 Mar '10

14 Mar '10

> <masarati(a)aero.polimi.it> wrote: > >> Please test. p. > > It works, but needs to adjustement to the master ACL. My basic > configuration yield me this at OTP bind on replica: > ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) > > replica slapd logs: > > conn=1001 op=0 RESULT tag=103 err=50 text= > SASL [conn=1001] Failure: Error putting OTP secret > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: > Error putting OTP secret" > > This has been fixed on the master, by adding this at the beginning of > the ACL: > > access to * attrs=cmusaslsecretOTP > by dn.regex="cn=replica,o=test" write stop > by * break This is orthogonal to the sasl auxprops discussion. It's a matter of well-configuring the authorizing identity in slapo-chain(5). > Another point: bind on the replica is impossible when the master is > down. I understand this is to prevent replaying the same OTP on multiple > replicas, but that defeats the purpose of setting up replicas for fail > over. This was clearly pointed out at the beginning of the discussion. You can't have both, it should be clear. > What about making the behavior configurable? Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is used, OTP breaks. If it is acceptable to have it broken, we can remove the hardcoding, and let admins decide whether they prefer fail-over over consistency. I'd have no doubt, and favor consistency. p.

1 0

Re: ITS#6475
by manu＠netbsd.org 14 Mar '10

14 Mar '10

<masarati(a)aero.polimi.it> wrote: > Please test. p. It works, but needs to adjustement to the master ACL. My basic configuration yield me this at OTP bind on replica: ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) replica slapd logs: conn=1001 op=0 RESULT tag=103 err=50 text= SASL [conn=1001] Failure: Error putting OTP secret send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: Error putting OTP secret" This has been fixed on the master, by adding this at the beginning of the ACL: access to * attrs=cmusaslsecretOTP by dn.regex="cn=replica,o=test" write stop by * break Another point: bind on the replica is impossible when the master is down. I understand this is to prevent replaying the same OTP on multiple replicas, but that defeats the purpose of setting up replicas for fail over. What about making the behavior configurable? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#6490) dds and pcache overlays not checking NULL value
by etienne.bagnoud＠irovision.ch 10 Mar '10

10 Mar '10

Full_Name: Etienne Bagnoud Version: 2.4.11 and HEAD OS: Debian GNU/Linux 5.0.4 URL: http://www.tchetch.net/code/openldap/ Submission from: (NULL) (153.109.35.2) When sending a refresh request (RFC 2589) with an empty DN, the server segfault. This did work on default Debian installed version (slapd 2.4.11) as well as on the actual (today) version in HEAD. The actual return value returned by 'select_backend' is not checked for NULL value and passed directly to 'SLAP_DYNAMIC' macro. While digging through the code to find how others overlays where doing, if found that pcache has the same behavior. I can't test for that overlay (if the bug is corrected or not), but I suppose it's the same. So here are two patches to correct dds overlay and pcache overlay : - http://www.tchetch.net/code/openldap/servers-slapd-overlays-dds.patch - http://www.tchetch.net/code/openldap/servers-slapd-overlays-pcache.patch I'm not used to dig into openldap code (in fact, this is the first time), so I hope it's ok. Etienne.

1 0

(ITS#6489) Incomplete Master/Slave Replication
by Frank.Offermanns＠caseris.de 09 Mar '10

09 Mar '10

Full_Name: Frank Offermanns Version: 2.4.21 OS: Windwos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am testing master/slave replication while adding 10000 users with 10 filled attributes. I am not using a specific time synchronization. Standard windows time synchronization in domains is active. But as far as I understood, a microsecond time synchronisation is only needed for master-master, which I am not testing. My problem is, that not every user and/or every attribute is replicated from my master to my slave. If the replicationmode is refreshAndPersist more entries are incorrect on the slave. When doing refreshOnly (every 5 mins) fewer entries have this problem. Switching to delta-syncrepl changes this behaviour. With delta-syncrepl once the intial content load has run, the replication seems to work 100%. But when I add entries while the inital content load (empty slave database) is running, a few complete users are missing (seems to be always a few in a row). But every written user has all attributes, so no missing attributes in this case. I will post my configuration (for refreshAndPersist replication). If you need any other info please let me known. Here my configurations: Master: ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 pidfile ./run/slapd.pid argsfile ./run/slapd.args access to * by dn.one="ou=Admins,o=caesar" write by * read ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" rootpw {SHA}secret... directory "c:/all2421/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 10000 ________________________________________________ Slave: ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 pidfile ./run/slapd.pid argsfile ./run/slapd.args access to * by dn.one="ou=Admins,o=caesar" write by * read ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" rootpw {SHA}secret.... directory "c:/all2421_48/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq syncrepl rid=001 provider="ldap://CAS-WS091201.domain.local" searchbase="o=caesar" type=refreshAndPersist retry="5 3 15 +" binddn="cn=Administrator,o=caesar" bindmethod=simple credentials="secret" sizelimit size.soft=100 size.hard=1000 size.prtotal=unlimited limits dn.exact="cn=Administrator,o=caesar" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 08 Mar '10

08 Mar '10

The original patch compiled but didn't run correctly due to a function that was removed. A new patch that fixes this issue is at: http://hawking.cluenet.org/~crispy/nssov-nsspamldapd-update.patch

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by tjoen＠dds.nl 08 Mar '10

08 Mar '10

On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: > After some chatter on the mailing list, the problem is now understood: > - TLS error messages are indeed reported by OpenLDAP: > TLS: could not use key file `/usr/local/etc/openldap/certs/ldap.key.pem'. ... > - The only way to see these error messages is to start the daemon with > '-d stats' ... > My suggestions: print the TLS error messages out to syslog, or if that's > not possible, print them to stdout regardless of whether the daemon is > running in the foreground or not. Isn't it in local4.* ?

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 08 Mar '10

08 Mar '10

After some chatter on the mailing list, the problem is now understood: - TLS error messages are indeed reported by OpenLDAP: TLS: could not use key file `/usr/local/etc/openldap/certs/ldap.key.pem'. TLS: error:0200100D:system library:fopen:Permission denied /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:356 TLS: error:20074002:BIO routines:FILE_CTRL:system lib /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:358 TLS: error:140B0002:SSL routines:SSL_CTX_use_PrivateKey_file:system lib /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:648 - The only way to see these error messages is to start the daemon with '-d stats' -- Setting 'loglevel stats' in slapd.conf will not cause these error messages to be printed. They only appear if the daemon is started in foreground mode with '-d stats'. My suggestions: print the TLS error messages out to syslog, or if that's not possible, print them to stdout regardless of whether the daemon is running in the foreground or not.

1 0

(ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 06 Mar '10

06 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: http://scalar.cluenet.org/~crispy/nssov-nsspamldapd-update.patch Submission from: (NULL) (98.212.227.43) The nssov overlay currently includes a very old version of the nss-ldapd (now nss-pam-ldapd) source. It's not necessary to keep a source tree of nss-pam-ldapd within openldap now, as the patches for pam_ldap support in the stub library were integrated upstream. This patch removes the nss-ldapd source tree from nssov, except for a few files which are unlikely to change, and on which nssov depends. This patch also updates nssov to support the newer versions of nss-pam-ldapd. There were some organizational changes, header changes, and changes of the names of constants since the version of nss-ldapd that is currently in the source. This patch also removes the dependence on the configure script of nss-ldapd. Currently, the configure script has to be run in the nss-ldapd subdirectory to generate a few constants which are needed by the parts of nss-ldapd that nssov depends on. These same constants are generated by the openldap configure script, and this patch changes the include path to include the relevant header from the openldap configure script, instead of requiring a separate configure script from nss-ldapd. This patch also updates the nssov Makefile to use the new nss-pam-ldapd files location and to create an install target that is separate from the all target. The README and man page are updated to reflect that nss-ldapd is no longer included in the source, and point to where to get it. They are also changed to reflect the new name of nss-ldapd: nss-pam-ldapd The patch is at: http://scalar.cluenet.org/~crispy/nssov-nsspamldapd-update.patch It applies on the nssov directory.

1 0

Re: (ITS#6486) OpenLDAP Admin Guide Backends Documentation
by hyc＠symas.com 05 Mar '10

05 Mar '10

ghenry(a)OpenLDAP.org wrote: > Thanks Ryan. > > I'll make sure this gets updated when I work through updating everything for cn=config syntax. > > Gavin. I already committed a patch to HEAD... http://www.openldap.org/lists/openldap-commit/201003/msg00007.html -- -- 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#6486) OpenLDAP Admin Guide Backends Documentation
by ghenry＠OpenLDAP.org 05 Mar '10

05 Mar '10

Thanks Ryan. I'll make sure this gets updated when I work through updating everything for cn=config syntax. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6487) Nssov pam_authz authorizedUserService
by crispy＠cluenet.org 04 Mar '10

04 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: http://paste.cluenet.org/pastebin.php?dl=2648 Submission from: (NULL) (98.212.227.43) My organization needs the capability of per-user (instead of per-group) access control with nssov. Using the method of modifying slapd ACLs to grant or revoke compare privileges on the authorizedService attribute of the host object is not scalable with large numbers of users, each of which have individual access. This patch adds an attribute "authorizedUserService" for use in a host entry. The attribute is in the form of "UID:SERVICE". If an attribute value for the user and service exists, access is granted. Otherwise access is denied. Wildcards in the form of "UID:*", "*:UID", and "*:*" are also supported. This patch also fixes a minor bug in the pam_authz function. Currently, one of the values read from NSCLD is used as a string in a Debug statement without initializing a NULL terminator. The patch extends the lengths of each buffer by 1 and initializes them to 0 so each buffer is always null-terminated and can be used as a string. The patch applies to the latest CVS HEAD as of this report, since several changes have been made in that region of code since 2.4.21. The patch is at http://paste.cluenet.org/pastebin.php?dl=2648 or http://paste.cluenet.org/2648

1 0

Re: (ITS#6485) nssov pam_authz fixes
by hyc＠symas.com 03 Mar '10

03 Mar '10

crispy(a)cluenet.org wrote: > Full_Name: Chris Breneman > Version: 2.4.21 > OS: Debian Lenny > URL: > Submission from: (NULL) (98.212.227.43) > > > In pam_authz(), in pam.c, in nssov, there are two problems: > > 1. Values in the service buffer are overwritten, and values in several other > buffers are never stored, preventing authorizedService checking from working. > 2. pam_authz() fails if nssov is not first used for authentication. Thanks for reporting these, fixes are 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#6433) patch for the sha2 module: hash methods for passwords generation
by hyc＠symas.com 03 Mar '10

03 Mar '10

cdelfosse(a)mandriva.com wrote: > Full_Name: Cédric Delfosse > Version: HEAD > OS: Mandriva Linux > URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch > Submission from: (NULL) (62.212.120.90) > > > Hello, > > this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes > (provided by the sha2 module) with LDAP Password Modify Extended Operations. > This patch contains the required hash methods. > > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Mandriva. Mandriva has not assigned rights and/or interest in this work to any > party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release > this work under the following terms. > > Mandriva 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. > > Regards, > > Cédric > Thanks, nice work. Committed 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

(ITS#6486) OpenLDAP Admin Guide Backends Documentation
by ryans＠aweber.com 03 Mar '10

03 Mar '10

Full_Name: Ryan Steele Version: 2.4.18 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The Admin Guide section on backends is inconsistent in terms of specifying the moduleload statement, and whether or not it is required for any arbitrary backend. For example, the documentation on back-ldif explicitly states that it is not needed: >You'll notice that when compared to examples below, there is no: > > moduleload back_ldif.la > >directive. This is because back_ldif is always built in by default as it is used by >slapd-config(5), which again is built in by default. This is in contrast to the monitor backend configuration section where it is noted as being required: >You can however set a rootdn and rootpw. The following is all that is needed to >instantiate a monitor backend: > > include ./schema/core.schema > > modulepath /usr/local/libexec/openldap > moduleload back_monitor.la > > database monitor > rootdn "cn=monitoring,cn=Monitor" > rootpw monitoring Or, in the back-ldap configuration section, where mention is omitted entirely: > database ldap > suffix "dc=suretecsystems,dc=com" > rootdn "cn=slapd-ldap" > uri ldap://localhost/ ldap://remotehost ldap://remotehost2 I should note that this ITS is not referring sections in which the configuration section for a backend is missing entirely (such as back-meta), because IMHO the lack of information there precludes it from being subject to the aforementioned ambiguity. I made sure to check with #openldap on Freenode (2010-03-03, 14:05 EST) before submitting this ITS, and have made sure to obtain Howard's blessing: <hyc> go ahead and submit an ITS. I don't think you need to attach a patch. <hyc> probably we'll just add a bluurb at the top "if your installation uses dynamic modules, you may need to add the relevant moduleload directives to the following examples" <hyc> and leave it at that.

1 0

(ITS#6485) nssov pam_authz fixes
by crispy＠cluenet.org 02 Mar '10

02 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: Submission from: (NULL) (98.212.227.43) In pam_authz(), in pam.c, in nssov, there are two problems: 1. Values in the service buffer are overwritten, and values in several other buffers are never stored, preventing authorizedService checking from working. 2. pam_authz() fails if nssov is not first used for authentication.

1 0

(ITS#6484) slapd 2.4.21 + pcache + rwm coredump
by mhardin＠symas.com 02 Mar '10

02 Mar '10

Full_Name: Matt Hardin Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.92.245) A naming context that uses back-ldap, slapo-rwm, and slapo-pcache dumps core when asked to perform an operation. Configuration snippets: database ldap suffix "dc=ad,dc=example,dc=com" subordinate rootdn "dc=ad,dc=example,dc=com" uri "ldaps://ldap01.example.com ldaps://ldap02.example.com" norefs yes chase-referrals no conn-ttl 300 network-timeout 10 use-temporary-conn yes # Identity assertion: connections authenticated as either of the two identities # below will connect to AD as the proxy user. Connections authenticated as # anything else (i.e., AD users) use those credentials for authentication. idassert-bind bindmethod=simple binddn="cn=cnsproxy,dc=example,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,dc=example,dc=com" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. We also take this # opportunity to 'lose' certain other attributes that have no place in # UNIX. overlay rwm rwm-normalize-mapped-attrs yes rwm-suffixmassage "dc=ad,dc=example,dc=com" "dc=example,dc=com" rwm-map objectClass posixAccount user rwm-map attribute uid samAccountName rwm-map attribute "" gecos [lots of rwm-map statements removed] # Caching setup overlay pcache proxycache hdb 100000 2 10000 50000 proxycachequeries 20000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass memberUid member proxyattrset 1 * # proxytemplate (&(objectClass=)(uid=)) 0 3600 300 proxytemplate (&(objectClass=)(uid=)) 1 3600 300 proxytemplate (&(objectClass=)(uidNumber=)) 0 3600 300 proxytemplate (&(objectClass=)(member=)) 0 3600 300 proxytemplate (&(objectClass=)(|(memberUid=)(member=))) 0 3600 300 proxytemplate (uid=) 0 3600 300 proxytemplate (&(objectClass=)(cn=)) 0 3600 300 proxytemplate (&(objectClass=)(gidNumber=)) 0 3600 300 proxytemplate (objectClass=*) 0 3600 300 # directory /var/symas/openldap-data/example-pcache cachesize 10000 idlcachesize 10000 checkpoint 512 600 sizelimit unlimited index objectClass eq index cn,sn,uid eq index uidNumber eq index gidNumber eq index memberUid eq index member eq index queryid eq dbconfig set_cachesize 0 536870912 0 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 Backtrace is as follows: (gdb) thr apply all bt Thread 5 (process 19756): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abc297 in pthread_join () from /lib/tls/libpthread.so.0 #2 0x00608524 in ldap_pvt_thread_join (thread=4294967292, thread_return=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:197 #3 0x0806f48a in slapd_daemon () at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2840 #4 0x0805896d in main (argc=7, argv=0xbfe4d694) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/main.c:961 Thread 4 (process 19757): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0070a1ce in epoll_wait () from /lib/tls/libc.so.6 #2 0x0806e505 in slapd_daemon_task (ptr=0x0) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2465 #3 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 3 (process 19759): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672 #4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #5 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 2 (process 19760): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672 #4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #5 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 1 (process 19758): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00665825 in raise () from /lib/tls/libc.so.6 #2 0x00667289 in abort () from /lib/tls/libc.so.6 #3 0x0065eda1 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0807bc34 in entry_clean (e=0x835ccdc) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:483 #5 0x0807bc52 in entry_free (e=0x835ccdc) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:514 #6 0x080da90e in overlay_entry_release_ov (op=0x838b5a0, e=0x835ccdc, rw=0, on=0x82fcb50) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:439 #7 0x0093aa55 in rwm_send_entry (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1508 #8 0x0093b129 in rwm_response (op=0x838b5a0, rs=0x6) ---Type <return> to continue, or q <return> to quit--- at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1700 #9 0x080da44a in over_back_response (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:237 #10 0x08081be0 in slap_response_play (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:358 #11 0x0808439b in slap_send_search_entry (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:843 #12 0x00bd8005 in hdb_search (op=0x838b5a0, rs=0x3a1a100) at search.c:961 #13 0x00a7d495 in pcache_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/pcache.c:3029 #14 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search, oi=0x82fca50, on=0x8303408) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659 #15 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721 #16 0x080d8f18 in glue_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backglue.c:457 #17 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search, oi=0x8302778, on=0x8302878) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659 #18 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721 #19 0x08074b36 in fe_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:366 #20 0x08074041 in do_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:217 #21 0x08072205 in connection_operation (ctx=0x3a1a210, arg_v=0x838b5a0) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1109 ---Type <return> to continue, or q <return> to quit--- #22 0x08072b54 in connection_read_thread (ctx=0x3a1a210, argv=0x18) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1245 #23 0x006077c6 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:685 #24 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #25 0x00709b4e in clone () from /lib/tls/libc.so.6 (gdb) q Commentary from debugging session: the entry in question is owned by pcache's cache DB and the overlay_entry_release() function didn't fall into the right release hook because the pcache overlay didn't provide one so this has to be fixed by adding a release hook to pcache not a big deal. so the fault isn't in rwm this time, it's calling the right API

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 01 Mar '10

01 Mar '10

--=-wu98lDL/cs9xvAtVkpXf Content-Type: multipart/mixed; boundary="=-bGZqaJas0lpiam3pf2jA" --=-bGZqaJas0lpiam3pf2jA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote: > On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > > [Resending because I forgot the ITS number in the subject] > >=20 > > I have a simple prototype that on add/modrdn populates/maintains an > > attribute (rdnValue) with the distinguished values of the naming > > attributes of the RDN. While doing this, it also checks for uniqueness= of > > the rdnValue value within siblings. > >=20 > > You can find it here > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.= 2.c> > >=20 > > Please test and comment. I hope it does what intended. >=20 > I'm starting to look at this now. I'm sorry so many months have past > since you posted it. I've now added it into Samba's provision, and using the diff I attach, against current 'master', I get the attached error. It seems to be unable to add the base DN. (The very first entry in the database). Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-bGZqaJas0lpiam3pf2jA Content-Disposition: attachment; filename="rdnval-use-in-samba.diff" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="rdnval-use-in-samba.diff"; charset="UTF-8" ZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zYW1iYV9kc2RiLmMg Yi9zb3VyY2U0L2RzZGIvc2FtZGIvbGRiX21vZHVsZXMvc2FtYmFfZHNkYi5jDQppbmRleCBjOTI5 ZDY1Li5jOGQ1YjkzIDEwMDY0NA0KLS0tIGEvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVz L3NhbWJhX2RzZGIuYw0KKysrIGIvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVzL3NhbWJh X2RzZGIuYw0KQEAgLTE3NSw3ICsxNzUsNiBAQCBzdGF0aWMgaW50IHNhbWJhX2RzZGJfaW5pdChz dHJ1Y3QgbGRiX21vZHVsZSAqbW9kdWxlKQ0KIAkJCQkJICAgICAiYXNxIiwNCiAJCQkJCSAgICAg ImV4dGVuZGVkX2RuX3N0b3JlIiwNCiAJCQkJCSAgICAgImV4dGVuZGVkX2RuX2luIiwNCi0JCQkJ CSAgICAgInJkbl9uYW1lIiwNCiAJCQkJCSAgICAgIm9iamVjdGNsYXNzIiwNCiAJCQkJCSAgICAg ImRlc2NyaXB0b3IiLA0KIAkJCQkJICAgICAiYWNsIiwNCkBAIC0xOTEsNiArMTkwLDcgQEAgc3Rh dGljIGludCBzYW1iYV9kc2RiX2luaXQoc3RydWN0IGxkYl9tb2R1bGUgKm1vZHVsZSkNCiAJY29u c3QgY2hhciAqKmxpbmtfbW9kdWxlczsNCiAJc3RhdGljIGNvbnN0IGNoYXIgKnRkYl9tb2R1bGVz X2xpc3RbXSA9IHsNCiAJCSJzdWJ0cmVlX2RlbGV0ZSIsDQorCQkicmRuX25hbWUiLA0KIAkJInJl cGxfbWV0YV9kYXRhIiwNCiAJCSJzdWJ0cmVlX3JlbmFtZSIsDQogCQkibGlua2VkX2F0dHJpYnV0 ZXMiLA0KZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVf bGRhcF9tYXAuYyBiL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9t YXAuYw0KaW5kZXggYmY5Y2Q0Zi4uNWVjN2E0YSAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvZHNkYi9z YW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9tYXAuYw0KKysrIGIvc291cmNlNC9kc2RiL3Nh bWRiL2xkYl9tb2R1bGVzL3NpbXBsZV9sZGFwX21hcC5jDQpAQCAtMjg3LDcgKzI4Nyw3IEBAIHN0 YXRpYyBjb25zdCBzdHJ1Y3QgbGRiX21hcF9hdHRyaWJ1dGUgZW50cnl1dWlkX2F0dHJpYnV0ZXNb XSA9DQogCQkudHlwZSA9IExEQl9NQVBfUkVOQU1FLA0KIAkJLnUgPSB7DQogCQkJLnJlbmFtZSA9 IHsNCi0JCQkJIC5yZW1vdGVfbmFtZSA9ICJzYW1iYTRSRE4iDQorCQkJCSAucmVtb3RlX25hbWUg PSAicmRudmFsIg0KIAkJCSB9DQogCQl9DQogCX0sDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1 cC9zY2hlbWEtbWFwLW9wZW5sZGFwLTIuMyBiL3NvdXJjZTQvc2V0dXAvc2NoZW1hLW1hcC1vcGVu bGRhcC0yLjMNCmluZGV4IDBkMzg2NTIuLmFlZDU0MDIgMTAwNjQ0DQotLS0gYS9zb3VyY2U0L3Nl dHVwL3NjaGVtYS1tYXAtb3BlbmxkYXAtMi4zDQorKysgYi9zb3VyY2U0L3NldHVwL3NjaGVtYS1t YXAtb3BlbmxkYXAtMi4zDQpAQCAtMTUsNiArMTUsOSBAQCB1aWROdW1iZXINCiBnaWROdW1iZXIN CiAjVGhlIG1lbWJlck9mIHBsdWdpbiBwcm92aWRlcyB0aGlzIGF0dHJpYnV0ZQ0KIG1lbWJlck9m DQorIyduYW1lJyBpcyB0aGUgUkROIGluIEFELCBidXQgc29tZXRoaW5nIGVsc2UgaW4gT3BlbkxE QVAuICBTa2lwIGFuZA0KKyMgdXNlIHRoZSBPcGVuTERBUCBvbmUNCituYW1lDQogI1RoZXNlIGNv bmZsaWN0IHdpdGggT3BlbkxEQVAgYnVpbHRpbnMNCiBhdHRyaWJ1dGVUeXBlczpzYW1iYTRBdHRy aWJ1dGVUeXBlcw0KIDIuNS4yMS41OjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNw0KQEAgLTI0LDgg KzI3LDYgQEAgb2JqZWN0Q2xhc3NlczpzYW1iYTRPYmplY3RDbGFzc2VzDQogMi41LjIxLjY6MS4z LjYuMS40LjEuNzE2NS40LjI1NS41DQogc3ViU2NoZW1hOnNhbWJhNFN1YlNjaGVtYQ0KIDIuNS4y MC4xOjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNA0KLSMnbmFtZScgaXMgdGhlIFJETiBpbiBBRCwg YnV0IHNvbWV0aGluZyBlbHNlIGluIE9wZW5MREFQDQotbmFtZTpzYW1iYTRSRE4NCiAjUmVtYXAg dGhlc2Ugc28gdGhhdCB3ZSBkb24ndCBwdXQgb3BlcmF0aW9uYWwgYXR0cmlidXRlcyBpbiBhIHNj aGVtYSBNQVkNCiBtb2RpZnlUaW1lU3RhbXA6c2FtYmE0TW9kaWZ5VGltZXN0YW1wDQogMi41LjE4 LjI6MS4zLjYuMS40LjEuNzE2NS40LjI1NS4zDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1cC9z bGFwZC5jb25mIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQppbmRleCAwMDc3YTIyLi5lNWZj ZDA2IDEwMDY0NA0KLS0tIGEvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQorKysgYi9zb3VyY2U0 L3NldHVwL3NsYXBkLmNvbmYNCkBAIC00OSw2ICs0OSw3IEBAIGRlZmF1bHRzZWFyY2hiYXNlICR7 RE9NQUlORE59DQogcm9vdGRuIGNuPU1hbmFnZXINCiANCiBvdmVybGF5IGRlcmVmDQorb3Zlcmxh eSByZG52YWwNCiANCiAke1JFRklOVF9DT05GSUd9DQogDQo= --=-bGZqaJas0lpiam3pf2jA Content-Disposition: attachment; filename="rdnval-errors.txt" Content-Transfer-Encoding: base64 Content-Type: text/plain; name="rdnval-errors.txt"; charset="UTF-8" PT4gZ2V0X2N0cmxzDQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX2R1bXA6IGJ1Zj0weDE2 MjlmMjAgcHRyPTB4MTYyYTkwMSBlbmQ9MHgxNjJhOTFlIGxlbj0yOQ0KICAwMDAwOiAgMzAgMWIg MDQgMTkgMzEgMmUgMzMgMmUgIDM2IDJlIDMxIDJlIDM0IDJlIDMxIDJlICAgMC4uLjEuMy42LjEu NC4xLiAgDQogIDAwMTA6ICAzNCAzMiAzMCAzMyAyZSAzNiAzNiAzNiAgMmUgMzUgMmUgMzEgMzIg ICAgICAgICAgICA0MjAzLjY2Ni41LjEyICAgICANCj0+IGdldF9jdHJsczogb2lkPSIxLjMuNi4x LjQuMS40MjAzLjY2Ni41LjEyIiAobm9uY3JpdGljYWwpDQo8PSBnZXRfY3RybHM6IG49MSByYz0w IGVycj0iIg0KPj4+IGRuUHJldHR5Tm9ybWFsOiA8REM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20+ DQo9PiBsZGFwX2J2MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tLDApDQo8PSBsZGFwX2J2 MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8 PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi digyNzIpDQo8PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPDw8 IGRuUHJldHR5Tm9ybWFsOiA8ZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20+LCA8ZGM9c2FtYmEs ZGM9ZXhhbXBsZSxkYz1jb20+DQpjb25uPTEwMDEgb3A9NSBBREQgZG49ImRjPXNhbWJhLGRjPWV4 YW1wbGUsZGM9Y29tIg0KPj4+IGRuUHJldHR5OiA8Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049 Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT4NCj0+IGxkYXBfYnYyZG4o Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFt cGxlLERDPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihDTj1Eb21haW4tRE5TLENOPVNjaGVtYSxDTj1D b25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi digyNzIpDQo8PSBsZGFwX2RuMmJ2KGNuPURvbWFpbi1ETlMsY249U2NoZW1hLGNuPUNvbmZpZ3Vy YXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5QcmV0dHk6IDxjbj1E b21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs ZGM9Y29tPg0KPj4+IGRuTm9ybWFsaXplOiA8Y249RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29u ZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbT4NCj0+IGxkYXBfYnYyZG4oY249 RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29uZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxl LGRjPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihjbj1Eb21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25m aWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigy NzIpDQo8PSBsZGFwX2RuMmJ2KGNuPWRvbWFpbi1kbnMsY249c2NoZW1hLGNuPWNvbmZpZ3VyYXRp b24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5Ob3JtYWxpemU6IDxjbj1k b21haW4tZG5zLGNuPXNjaGVtYSxjbj1jb25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs ZGM9Y29tPg0Kc3RyMmZpbHRlciAiKHJkblZhbHVlPXNhbWJhKSINCnB1dF9maWx0ZXI6ICIocmRu VmFsdWU9c2FtYmEpIg0KcHV0X2ZpbHRlcjogc2ltcGxlDQpwdXRfc2ltcGxlX2ZpbHRlcjogInJk blZhbHVlPXNhbWJhIg0KYmVnaW4gZ2V0X2ZpbHRlcg0KRVFVQUxJVFkNCmJlcl9zY2FuZiBmbXQg KHttbX0pIGJlcjoNCmJlcl9kdW1wOiBidWY9MHg3ZjQ2Y2M4NzgxZjggcHRyPTB4N2Y0NmNjODc4 MWY4IGVuZD0weDdmNDZjYzg3ODIwYiBsZW49MTkNCiAgMDAwMDogIGEzIDExIDA0IDA4IDcyIDY0 IDZlIDU2ICA2MSA2YyA3NSA2NSAwNCAwNSA3MyA2MSAgIC4uLi5yZG5WYWx1ZS4uc2EgIA0KICAw MDEwOiAgNmQgNjIgNjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bWJhICAgICAgICAgICAgICAgDQplbmQgZ2V0X2ZpbHRlciAwDQpzZW5kX2xkYXBfcmVzdWx0OiBj b25uPTEwMDEgb3A9NSBwPTMNCnNlbmRfbGRhcF9yZXN1bHQ6IGVycj0xMCBtYXRjaGVkPSIiIHRl eHQ9IiINCnNlbmRfbGRhcF9yZXN1bHQ6IGNvbm49MTAwMSBvcD01IHA9Mw0Kc2VuZF9sZGFwX3Jl c3VsdDogZXJyPTE5IG1hdGNoZWQ9IiIgdGV4dD0icmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4g c2libGluZ3MiDQpzZW5kX2xkYXBfcmVzcG9uc2U6IG1zZ2lkPTYgdGFnPTEwNSBlcnI9MTkNCmJl cl9mbHVzaDI6IDQ5IGJ5dGVzIHRvIHNkIDIxDQogIDAwMDA6ICAzMCAyZiAwMiAwMSAwNiA2OSAy YSAwYSAgMDEgMTMgMDQgMDAgMDQgMjMgNzIgNjQgICAwLy4uLmkqLi4uLi4uI3JkICANCiAgMDAx MDogIDZlIDU2IDYxIDZjIDc1IDY1IDIwIDZlICA2ZiA3NCAyMCA3NSA2ZSA2OSA3MSA3NSAgIG5W YWx1ZSBub3QgdW5pcXUgIA0KICAwMDIwOiAgNjUgMjAgNzcgNjkgNzQgNjggNjkgNmUgIDIwIDcz IDY5IDYyIDZjIDY5IDZlIDY3ICAgZSB3aXRoaW4gc2libGluZyAgDQogIDAwMzA6ICA3MyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzICAgICAgICAgICAg ICAgICANCmxkYXBfd3JpdGU6IHdhbnQ9NDksIHdyaXR0ZW49NDkNCiAgMDAwMDogIDMwIDJmIDAy IDAxIDA2IDY5IDJhIDBhICAwMSAxMyAwNCAwMCAwNCAyMyA3MiA2NCAgIDAvLi4uaSouLi4uLi4j cmQgIA0KICAwMDEwOiAgNmUgNTYgNjEgNmMgNzUgNjUgMjAgNmUgIDZmIDc0IDIwIDc1IDZlIDY5 IDcxIDc1ICAgblZhbHVlIG5vdCB1bmlxdSAgDQogIDAwMjA6ICA2NSAyMCA3NyA2OSA3NCA2OCA2 OSA2ZSAgMjAgNzMgNjkgNjIgNmMgNjkgNmUgNjcgICBlIHdpdGhpbiBzaWJsaW5nICANCiAgMDAz MDogIDczICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHMg ICAgICAgICAgICAgICAgIA0KY29ubj0xMDAxIG9wPTUgUkVTVUxUIHRhZz0xMDUgZXJyPTE5IHRl eHQ9cmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4gc2libGluZ3MNClRyYWNlYmFjayAobW9zdCBy ZWNlbnQgY2FsbCBsYXN0KToNCiAgRmlsZSAiLi9zZXR1cC9wcm92aXNpb24iLCBsaW5lIDI0NSwg aW4gPG1vZHVsZT4NCiAgICBub3N5bmM9b3B0cy5ub3N5bmMsbGRhcF9kcnlydW5fbW9kZT1vcHRz LmxkYXBfZHJ5cnVuX21vZGUsdXNlZWFkYj1lYWRiKQ0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJh L3Byb3Zpc2lvbi5weSIsIGxpbmUgMTMwNSwgaW4gcHJvdmlzaW9uDQogICAgZG9tX2Zvcl9mdW5f bGV2ZWw9ZG9tX2Zvcl9mdW5fbGV2ZWwpDQogIEZpbGUgImJpbi9weXRob24vc2FtYmEvcHJvdmlz aW9uLnB5IiwgbGluZSA5MTIsIGluIHNldHVwX3NhbWRiDQogICAgIkRFU0NSSVBUT1IiOiBkZXNj cg0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJhL3Byb3Zpc2lvbi5weSIsIGxpbmUgMjM5LCBpbiBz ZXR1cF9hZGRfbGRpZg0KICAgIGxkYi5hZGRfbGRpZihkYXRhLGNvbnRyb2xzKQ0KICBGaWxlICJi aW4vcHl0aG9uL3NhbWJhL19faW5pdF9fLnB5IiwgbGluZSAyNTgsIGluIGFkZF9sZGlmDQogICAg c2VsZi5hZGQobXNnLGNvbnRyb2xzKQ0KX2xkYi5MZGJFcnJvcjogKDE5LCAnTERBUCBlcnJvciAx OSBMREFQX0NPTlNUUkFJTlRfVklPTEFUSU9OIC0gIDxyZG5WYWx1ZSBub3QgdW5pcXVlIHdpdGhp biBzaWJsaW5ncz4gPD4nKQ0K --=-bGZqaJas0lpiam3pf2jA-- --=-wu98lDL/cs9xvAtVkpXf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLjLtkz4A8Wyi0NrsRApu+AJ0cW7Vd8zPhS57s8r+iW3D5lFbNHQCgkYCP vgrrkMMEYjbxPtMqqgUHbrY= =ZH85 -----END PGP SIGNATURE----- --=-wu98lDL/cs9xvAtVkpXf--

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 01 Mar '10

01 Mar '10

--=-3cgveKzr2Byp6ib+VYg9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > [Resending because I forgot the ITS number in the subject] >=20 > I have a simple prototype that on add/modrdn populates/maintains an > attribute (rdnValue) with the distinguished values of the naming > attributes of the RDN. While doing this, it also checks for uniqueness o= f > the rdnValue value within siblings. >=20 > You can find it here > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.= c> >=20 > Please test and comment. I hope it does what intended. I'm starting to look at this now. I'm sorry so many months have past since you posted it. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-3cgveKzr2Byp6ib+VYg9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLjJRvz4A8Wyi0NrsRAqh2AJ4uvpxIGj0PTacpWVLVO18BRrWqaQCeOqhh VdZtFVltm6uv6qY3Lw7ULpk= =zoZi -----END PGP SIGNATURE----- --=-3cgveKzr2Byp6ib+VYg9--

1 0

Status of ITS 5941?
by Lars Kellogg-Stedman 01 Mar '10

01 Mar '10

Hello all, I think I've just run into ITS 5941 (http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5941). I'm trying to set up a proxy using the "translucent" overlay in front of an Active Directory server; I'd like to rewrite some attributes (e.g., sAMAccountName -> uid) as part of this process. The config looks like this: moduleload translucent moduleload rwm database ldif suffix "dc=dept,dc=example,dc=com" directory "/var/lib/ldap/ad-proxy" rootdn "cn=admin,dc=dept,dc=example,dc=com" rootpw "password" overlay translucent uri ldap://127.0.0.1/ acl-bind bindmethod=simple binddn=cn=binduser,ou=people,cn=admin,dc=dept,dc=example,dc=com credentials=password overlay rwm rwm-map attribute uid sAMAccountName With this configuration in place, I can complete one search, after which slapd dies with: Segmentation fault If I explicitly request the rewritten attribute: $ ldapsearch ... cn=lars uid Slapd dies with a backtrace: *** glibc detected *** slapd: double free or corruption (!prev): 0xb6602320 *** ======= Backtrace: ========= /lib/libc.so.6(+0x1b7751)[0x858751] slapd(ber_memfree_x+0x50)[0x610c40] slapd(slap_sl_free+0x70)[0x527240] slapd(do_search+0x17f)[0x4c819f] slapd(+0x3c15e)[0x4c515e] slapd(+0x15921c)[0x5e221c] /lib/libpthread.so.0(+0x2f8ab5)[0x334ab5] /lib/libc.so.6(clone+0x5e)[0x8c4dce] Does this look like the same problem? Is there a fix available? If not, is there a workaround that doesn't involve running a second instance of slapd as a rewriting proxy?

1 0

(ITS#6483) [PATCH] Properly use #elif
by delphij＠FreeBSD.org 01 Mar '10

01 Mar '10

Full_Name: Xin LI Version: -HEAD OS: FreeBSD/amd64 URL: http://people.freebsd.org/~delphij/misc/openldap-elif.diff Submission from: (NULL) (206.40.55.65) OpenLDAP uses several #elif to test if a macro is being defined, which should be spelled as #elif defined. Here is a patch against CVS -HEAD. Index: include/ac/regex.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/regex.h,v retrieving revision 1.20 diff -u -p -u -p -r1.20 regex.h --- include/ac/regex.h 21 Jan 2009 23:40:18 -0000 1.20 +++ include/ac/regex.h 1 Mar 2010 20:12:52 -0000 @@ -28,7 +28,7 @@ */ #error "No POSIX REGEX available." -#elif HAVE_GNUREGEX_H +#elif defined(HAVE_GNUREGEX_H) /* system has GNU gnuregex.h */ # include <gnuregex.h> #else Index: include/ac/signal.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/signal.h,v retrieving revision 1.28 diff -u -p -u -p -r1.28 signal.h --- include/ac/signal.h 21 Jan 2009 23:40:18 -0000 1.28 +++ include/ac/signal.h 1 Mar 2010 20:12:52 -0000 @@ -72,7 +72,7 @@ LDAP_LUTIL_F(lutil_sig_t) lutil_sigactio #ifndef LDAP_SIGCHLD #ifdef SIGCHLD #define LDAP_SIGCHLD SIGCHLD -#elif SIGCLD +#elif defined(SIGCLD) #define LDAP_SIGCHLD SIGCLD #endif #endif Index: include/ac/socket.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/socket.h,v retrieving revision 1.77 diff -u -p -u -p -r1.77 socket.h --- include/ac/socket.h 23 Oct 2009 10:29:50 -0000 1.77 +++ include/ac/socket.h 1 Mar 2010 20:12:52 -0000 @@ -62,7 +62,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif @@ -110,12 +110,12 @@ LBER_F( char * ) ber_pvt_wsa_err2string LDAP_P((int)); -#elif MACOS +#elif defined(MACOS) # define tcp_close( s ) tcpclose( s ) # define tcp_read( s, buf, len ) tcpread( s, buf, len ) # define tcp_write( s, buf, len ) tcpwrite( s, buf, len ) -#elif DOS +#elif defined(DOS) # ifdef PCNFS # define tcp_close( s ) close( s ) # define tcp_read( s, buf, len ) recv( s, buf, len, 0 ) Index: libraries/liblber/nt_err.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblber/nt_err.c,v retrieving revision 1.18 diff -u -p -u -p -r1.18 nt_err.c --- libraries/liblber/nt_err.c 21 Jan 2009 23:40:19 -0000 1.18 +++ libraries/liblber/nt_err.c 1 Mar 2010 20:12:52 -0000 @@ -17,7 +17,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif /* HAVE_WINSOCK(2) */ Index: libraries/libldap/init.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/init.c,v retrieving revision 1.123 diff -u -p -u -p -r1.123 init.c --- libraries/libldap/init.c 15 Nov 2009 20:48:49 -0000 1.123 +++ libraries/libldap/init.c 1 Mar 2010 20:12:52 -0000 @@ -616,7 +616,7 @@ void ldap_int_initialize( struct ldapopt return; } } /* The WinSock DLL is acceptable. Proceed. */ -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) { WSADATA wsaData; if ( WSAStartup( 0x0101, &wsaData ) != 0 ) { return; Index: libraries/liblutil/detach.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/detach.c,v retrieving revision 1.22 diff -u -p -u -p -r1.22 detach.c --- libraries/liblutil/detach.c 21 Jan 2009 23:40:23 -0000 1.22 +++ libraries/liblutil/detach.c 1 Mar 2010 20:12:52 -0000 @@ -128,7 +128,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_SETSID (void) setsid(); -#elif TIOCNOTTY +#elif defined(TIOCNOTTY) if ( (sd = open( "/dev/tty", O_RDWR )) != -1 ) { (void) ioctl( sd, TIOCNOTTY, NULL ); (void) close( sd ); Index: libraries/liblutil/entropy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/entropy.c,v retrieving revision 1.32 diff -u -p -u -p -r1.32 entropy.c --- libraries/liblutil/entropy.c 21 Jan 2009 23:40:23 -0000 1.32 +++ libraries/liblutil/entropy.c 1 Mar 2010 20:12:52 -0000 @@ -73,7 +73,7 @@ int lutil_entropy( unsigned char *buf, b close(fd); return nbytes > 0 ? -1 : 0; } -#elif PROV_RSA_FULL +#elif defined(PROV_RSA_FULL) { /* Not used since _WIN32_WINNT not set... */ HCRYPTPROV hProv = 0; [delphij@delta] ~/scratch/oo/ldap-src> cvs -qR diff -uNp > ~/openldap-elif.diff [delphij@delta] ~/scratch/oo/ldap-src> cat ~/open openldap-elif.diff openvpn.conf [delphij@delta] ~/scratch/oo/ldap-src> cat ~/openldap-elif.diff Index: include/ac/regex.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/regex.h,v retrieving revision 1.20 diff -u -p -u -p -r1.20 regex.h --- include/ac/regex.h 21 Jan 2009 23:40:18 -0000 1.20 +++ include/ac/regex.h 1 Mar 2010 20:13:03 -0000 @@ -28,7 +28,7 @@ */ #error "No POSIX REGEX available." -#elif HAVE_GNUREGEX_H +#elif defined(HAVE_GNUREGEX_H) /* system has GNU gnuregex.h */ # include <gnuregex.h> #else Index: include/ac/signal.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/signal.h,v retrieving revision 1.28 diff -u -p -u -p -r1.28 signal.h --- include/ac/signal.h 21 Jan 2009 23:40:18 -0000 1.28 +++ include/ac/signal.h 1 Mar 2010 20:13:03 -0000 @@ -72,7 +72,7 @@ LDAP_LUTIL_F(lutil_sig_t) lutil_sigactio #ifndef LDAP_SIGCHLD #ifdef SIGCHLD #define LDAP_SIGCHLD SIGCHLD -#elif SIGCLD +#elif defined(SIGCLD) #define LDAP_SIGCHLD SIGCLD #endif #endif Index: include/ac/socket.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/socket.h,v retrieving revision 1.77 diff -u -p -u -p -r1.77 socket.h --- include/ac/socket.h 23 Oct 2009 10:29:50 -0000 1.77 +++ include/ac/socket.h 1 Mar 2010 20:13:03 -0000 @@ -62,7 +62,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif @@ -110,12 +110,12 @@ LBER_F( char * ) ber_pvt_wsa_err2string LDAP_P((int)); -#elif MACOS +#elif defined(MACOS) # define tcp_close( s ) tcpclose( s ) # define tcp_read( s, buf, len ) tcpread( s, buf, len ) # define tcp_write( s, buf, len ) tcpwrite( s, buf, len ) -#elif DOS +#elif defined(DOS) # ifdef PCNFS # define tcp_close( s ) close( s ) # define tcp_read( s, buf, len ) recv( s, buf, len, 0 ) Index: libraries/liblber/nt_err.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblber/nt_err.c,v retrieving revision 1.18 diff -u -p -u -p -r1.18 nt_err.c --- libraries/liblber/nt_err.c 21 Jan 2009 23:40:19 -0000 1.18 +++ libraries/liblber/nt_err.c 1 Mar 2010 20:13:03 -0000 @@ -17,7 +17,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif /* HAVE_WINSOCK(2) */ Index: libraries/libldap/init.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/init.c,v retrieving revision 1.123 diff -u -p -u -p -r1.123 init.c --- libraries/libldap/init.c 15 Nov 2009 20:48:49 -0000 1.123 +++ libraries/libldap/init.c 1 Mar 2010 20:13:03 -0000 @@ -616,7 +616,7 @@ void ldap_int_initialize( struct ldapopt return; } } /* The WinSock DLL is acceptable. Proceed. */ -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) { WSADATA wsaData; if ( WSAStartup( 0x0101, &wsaData ) != 0 ) { return; Index: libraries/liblutil/detach.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/detach.c,v retrieving revision 1.22 diff -u -p -u -p -r1.22 detach.c --- libraries/liblutil/detach.c 21 Jan 2009 23:40:23 -0000 1.22 +++ libraries/liblutil/detach.c 1 Mar 2010 20:13:03 -0000 @@ -128,7 +128,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_SETSID (void) setsid(); -#elif TIOCNOTTY +#elif defined(TIOCNOTTY) if ( (sd = open( "/dev/tty", O_RDWR )) != -1 ) { (void) ioctl( sd, TIOCNOTTY, NULL ); (void) close( sd ); Index: libraries/liblutil/entropy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/entropy.c,v retrieving revision 1.32 diff -u -p -u -p -r1.32 entropy.c --- libraries/liblutil/entropy.c 21 Jan 2009 23:40:23 -0000 1.32 +++ libraries/liblutil/entropy.c 1 Mar 2010 20:13:03 -0000 @@ -73,7 +73,7 @@ int lutil_entropy( unsigned char *buf, b close(fd); return nbytes > 0 ? -1 : 0; } -#elif PROV_RSA_FULL +#elif defined(PROV_RSA_FULL) { /* Not used since _WIN32_WINNT not set... */ HCRYPTPROV hProv = 0;

1 0

(ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 01 Mar '10

01 Mar '10

Full_Name: Himmelbauer Version: 2.4.19 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/himmelbauer-100301.patch Submission from: (NULL) (92.248.100.200) Was not able to retrieve database entries from a corrupted LDAP database using slapcat (openldap 2.4.19) with option -c. It aborts after the first corrupted entry with <= entry_decode: slap_str2undef_ad(object�!p): AttributeDescription contains inappropriate characters # no data for entry id=xxxxxxxx and doesn't continue with the next valid entry as I would have expected. A damaged database is not good, but as slapcat is described as the tool to recover the non-corrupted data in various forums, it would be good when it really continues on errors. Other ldap-related tools like ldapsearch ignore the damaged data, so it is really annoying, when you want to recover your data and don't even get all the readable entries. The patch corrects the handling of damaged entries by slapcat when -c is used, so that the output is continued with the next non-damaged entry. When -c is not used slapcat stops after the first corrupted entry (as expected). The patch works for me, but I know that it is not really correct, because when there would be no non-damaged entry left it would either cause a endless loop or some crashes. So a modification would be needed to stop the loop when the last database entry was processed, but I didn't know how to access that id.

1 0

slapadd problem
by tjoen 28 Feb '10

28 Feb '10

Openldap 2.4.21, patched with openldap-ntlm.diff from evolution ./configure --prefix=/usr --enable-static Db 4.7.25 ./configure --prefix=/usr --enable-compat185 --disable-static Problem with smbldap-populate: # smbldap-populate Populating LDAP directory for domain WORKGROUP (S-1-5-21-686817777-1585854605-660948164) (using builtin directory structure) adding new entry: dc=example,dc=org adding new entry: ou=People,dc=example,dc=org adding new entry: ou=Groups,dc=example,dc=org entry ou=People,dc=example,dc=org already exist. adding new entry: ou=Idmap,dc=example,dc=org ^C (hangs) test1.ldif: dn: dc=example,dc=org objectclass: dcObject objectclass: organization dc: example o: Quenya Org Network description: The Samba-3 Network LDAP Example test2.ldif: dn: sambaDomainName=WORKGROUP,dc=example,dc=org objectclass: top objectClass: sambaDomain objectClass: sambaUnixIdPool sambaDomainName: WORKGROUP sambaSID: S-1-5-21-686817777-1585854605-660948164 uidNumber: 1000 gidNumber: 1000 sambaNextRid: 1000 # /etc/rc.d/init.d/ldap stop /var/openldap-data # rm __db.00* alock *.bdb log.0000000001 # slapadd -v -l test1.ldif added: "dc=example,dc=org" (00000001) _#################### 100.00% eta none elapsed none fast! Closing DB... # slapadd -v -l test2.ldif ^C (hangs) But: /var/openldap-data # rm __db.00* alock *.bdb log.0000000001 # slapadd -v -l test2.ldif added: "sambaDomainName=WORKGROUP,dc=example,dc=org" (00000002) _#################### 100.00% eta none elapsed none fast! Closing DB...Error, entries missing! entry 1: dc=example,dc=org # slapadd -v -l test1.ldif added: "dc=example,dc=org" (00000001) _#################### 100.00% eta none elapsed none fast! Closing DB... Why first test1 then test2 doesn't work? Deadlock? slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema pidfile /var/run/slapd.pid argsfile /var/run/slapd.args loglevel 256 idletimeout 30 access to dn.base="" by self write by * auth access to attrs=userPassword by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read by anonymous auth backend bdb database bdb cachesize 10000 suffix "dc=example,dc=org" checkpoint 1024 5 rootdn "cn=Manager,dc=example,dc=org" # /usr/sbin/slappasswd -s secret rootpw {SSHA}Z6Ton189xuv6t+OeUYxcGoLR+nZnh0Z6 directory /var/openldap-data # Indices to maintain index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub database monitor access to * by dn.exact="cn=Manager,dc=example,dc=org by * none

2 2

(ITS#6481) Asssert with acl-sets and referals
by raphael.ouazana＠linagora.com 25 Feb '10

25 Feb '10

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) When an URI is deferenced and when the server returns referals, an assertion is triggered in acl_set_cb_gather : assert( rs->sr_type == REP_RESULT ); It seems that sets don't handle the case where the search response is a REP_SEARCHREF. Regards, Raphaël Ouazana.

1 0

Re: ITS#6475
by manu＠netbsd.org 24 Feb '10

24 Feb '10

<masarati(a)aero.polimi.it> wrote: > It allows to configure what SASL auxprop names need the "dontUseCopy" > approach. The "cmusaslsecretOTP" is set by default, if known through the > schema. Seems nice. I hope I'll have time to test this week. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs