- openldap-bugs - openldap.org

Re: (ITS#6481) Asssert with acl-sets and referals
by raphael.ouazana＠linagora.com 24 Mar '10

24 Mar '10

Le Lun 22 mars 2010 21:51, masarati(a)aero.polimi.it a écrit : > Fixed in HEAD; please test. Thanks, p. > > Thank you, that seems to work fine. Regards, Raphael Ouazana.

1 0

(ITS#6498) SLAPI functions missing
by maci＠satgnu.net 24 Mar '10

24 Mar '10

Full_Name: Marcel Wysocki Version: 2.4.21 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.79.126.162) I noticed that all of the SLAPI functions do manipulate LDAPMod** are missing. from the fedora ds slapi-plugin.h: /* * LDAPMod manipulation routines */ Slapi_Mods* slapi_mods_new( void ); void slapi_mods_init(Slapi_Mods *smods, int initCount); void slapi_mods_init_byref(Slapi_Mods *smods, LDAPMod **mods); void slapi_mods_init_passin(Slapi_Mods *smods, LDAPMod **mods); void slapi_mods_free(Slapi_Mods **smods); void slapi_mods_done(Slapi_Mods *smods); void slapi_mods_insert_at(Slapi_Mods *smods, LDAPMod *mod, int pos); void slapi_mods_insert_smod_at(Slapi_Mods *smods, Slapi_Mod *smod, int pos); void slapi_mods_insert_before(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_insert_smod_before(Slapi_Mods *smods, Slapi_Mod *smod); void slapi_mods_insert_after(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_insert_after(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_add( Slapi_Mods *smods, int modtype, const char *type, unsigned long len, const char *val); void slapi_mods_add_ldapmod(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_add_modbvps( Slapi_Mods *smods, int modtype, const char *type, struct berval **bvps ); void slapi_mods_add_mod_values( Slapi_Mods *smods, int modtype, const char *type, Slapi_Value **va ); void slapi_mods_add_smod(Slapi_Mods *smods, Slapi_Mod *smod); void slapi_mods_add_string( Slapi_Mods *smods, int modtype, const char *type, const char *val); void slapi_mods_remove(Slapi_Mods *smods); LDAPMod *slapi_mods_get_first_mod(Slapi_Mods *smods); LDAPMod *slapi_mods_get_next_mod(Slapi_Mods *smods); Slapi_Mod *slapi_mods_get_first_smod(Slapi_Mods *smods, Slapi_Mod *smod); Slapi_Mod *slapi_mods_get_next_smod(Slapi_Mods *smods, Slapi_Mod *smod); void slapi_mods_iterator_backone(Slapi_Mods *smods); LDAPMod **slapi_mods_get_ldapmods_byref(Slapi_Mods *smods); LDAPMod **slapi_mods_get_ldapmods_passout(Slapi_Mods *smods); int slapi_mods_get_num_mods(const Slapi_Mods *smods); void slapi_mods_dump(const Slapi_Mods *smods, const char *text); Slapi_Mod* slapi_mod_new( void ); void slapi_mod_init(Slapi_Mod *smod, int initCount); void slapi_mod_init_byval(Slapi_Mod *smod, const LDAPMod *mod); void slapi_mod_init_byref(Slapi_Mod *smod, LDAPMod *mod); void slapi_mod_init_passin(Slapi_Mod *smod, LDAPMod *mod); /* init a mod and set the mod values to be a copy of the given valueset */ void slapi_mod_init_valueset_byval(Slapi_Mod *smod, int op, const char *type, const Slapi_ValueSet *svs); void slapi_mod_add_value(Slapi_Mod *smod, const struct berval *val); void slapi_mod_remove_value(Slapi_Mod *smod); struct berval *slapi_mod_get_first_value(Slapi_Mod *smod); struct berval *slapi_mod_get_next_value(Slapi_Mod *smod); const char *slapi_mod_get_type(const Slapi_Mod *smod); int slapi_mod_get_operation(const Slapi_Mod *smod); void slapi_mod_set_type(Slapi_Mod *smod, const char *type); void slapi_mod_set_operation(Slapi_Mod *smod, int op); int slapi_mod_get_num_values(const Slapi_Mod *smod); const LDAPMod *slapi_mod_get_ldapmod_byref(const Slapi_Mod *smod); LDAPMod *slapi_mod_get_ldapmod_passout(Slapi_Mod *smod); void slapi_mod_free(Slapi_Mod **smod); void slapi_mod_done(Slapi_Mod *mod); int slapi_mod_isvalid(const Slapi_Mod *mod); void slapi_mod_dump(LDAPMod *mod, int n); /* helper functions to translate between entry and a set of mods */ int slapi_mods2entry(Slapi_Entry **e, const char *dn, LDAPMod **attrs); int slapi_entry2mods(const Slapi_Entry *e, char **dn, LDAPMod ***attrs); there might be some more missing. most of it can be found in fedora ds's modutils.c should be worth porting to openldap

1 0

Re: (ITS#6478) slapd crashes with segfault
by masarati＠aero.polimi.it 24 Mar '10

24 Mar '10

> Hello, here is a backtrace > of the crash, however not yet from > a version with full debug symbols enabled. > We are still working on that. You rbacktrace, although incomplete, looks weird: > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 > #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 > #3 0x00000037a4e6da07 in malloc_consolidate () from /lib64/libc.so.6 > #4 0x00000037a4e6f1fb in _int_free () from /lib64/libc.so.6 > #5 0x00000037a4e72a6c in free () from /lib64/libc.so.6 > #6 0x00000037a4ecabda in __vsyslog_chk () from /lib64/libc.so.6 > #7 0x00000037a4ecaf33 in __syslog_chk () from /lib64/libc.so.6 > #8 0x0000000000437869 in slapd_remove () > #9 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 > #10 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 libc is raising an assertion during a free related to printing something on syslog. However, in slapd_remove() I don't see anything that could be harmful for syslog, as the only information that may be printed is printed at a very verbose loglevel, and basically consists of integers, so it seems impossible that things like NULL or invalid pointers slip through. p.

1 0

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

23 Mar '10

I found that there's an alternate way to achieve this same functionality that's more elegant, probably more efficient, and doesn't require any patches. The approach uses the authorizedService attributes on the host entry. With nssov, individual users can be granted or revoked access based on the slapd ACLs and whether or not they have "compare" access to the authorizedService attribute. I created groups of users underneath the host entry - one for each service - and used regex's in the ACLs to grant compare access to the correct authorizedService attribute when the user is present in the corresponding group. Also the buffer sizes were determined to be a non-issue and do not need to be changed. Chris Breneman On Mon, 2010-03-22 at 00:03 -0500, Kean Johnston wrote: > I like what this offers administrators but I have a comment about how you > handle "wildcards". They aren't wild at all, but "magic strings" with only > one possible meaning: all users/services with the single magic character > "*". If you have a defined user naming convention like i_whatever for > interns and c_whatever for contractors, it would be useful to be able to > either include or exclude such users from using certain services. > > My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for > userhost and userservices attributes, and includes negation. Would you be > interested in working with me to expand this to support real wildcards? > Also I suggest you make this two patches, as the patch submission > guidelines clearly state that one patch for 1 feature, and the meaty parts > of this are obfuscated by increasing the buffer sizes which should probably > be in a separate patch. > > Regards, Kean

1 0

Re: (ITS#6497) Infinite loop in translucent.c
by masarati＠aero.polimi.it 23 Mar '10

23 Mar '10

Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6478) slapd crashes with segfault
by wolfgang.hummel＠hp.com 23 Mar '10

23 Mar '10

Hello, here is a backtrace of the crash, however not yet from a version with full debug symbols enabled. We are still working on that. [root@ts2mstsv010 dumps]# gdb /usr/sbin/slapd core.slapd.12403 GNU gdb Red Hat Linux (6.5-25.el5rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbol= s found) Using host libthread_db library "/lib64/libthread_db.so.1". Reading symbols from /usr/lib64/libltdl.so.3...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...don= e. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libuuid.so.1...(no debugging symbols found)...d= one. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/lib64/libslapd_db-4.7.so...(no debugging symbols = found)...done. Loaded symbols for /usr/lib64/libslapd_db-4.7.so Reading symbols from /usr/lib64/libodbc.so.1...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib64/libodbc.so.1 Reading symbols from /usr/lib64/libsasl2.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libssl.so.6...(no debugging symbols found)...do= ne. Loaded symbols for /lib64/libssl.so.6 Reading symbols from /lib64/libcrypto.so.6...(no debugging symbols found)..= .done. Loaded symbols for /lib64/libcrypto.so.6 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...= done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)..= .done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libwrap.so.0...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib64/libwrap.so.0 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done= . Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols fo= und)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...(no debugging symbols= found)...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found).= ..done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...(no debugging symbols fo= und)...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /usr/lib64/libz.so.1...(no debugging symbols found)...= done. Loaded symbols for /usr/lib64/libz.so.1 Reading symbols from /lib64/libnsl.so.1...(no debugging symbols found)...do= ne. Loaded symbols for /lib64/libnsl.so.1 Reading symbols from /usr/lib64/libkrb5support.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)= ...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found).= ..done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libsepol.so.1...(no debugging symbols found)...= done. Loaded symbols for /lib64/libsepol.so.1 Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found).= ..done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /lib64/libnss_files.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so.2...(no debugging symbols= found)...done. Loaded symbols for /usr/lib64/sasl2/libplain.so.2 Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...(no debugging sym= bols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 Reading symbols from /usr/lib64/sasl2/liblogin.so.2...(no debugging symbols= found)...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 Reading symbols from /usr/lib64/openldap/syncprov-2.4.so.2...(no debugging = symbols found)...done. Loaded symbols for /usr/lib64/openldap/syncprov-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_template-2.4.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/openldap/cms_template-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_modif-2.4.so.2...(no debugging= symbols found)...done. Loaded symbols for /usr/lib64/openldap/cms_modif-2.4.so.2 Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols found)...= done. Loaded symbols for /lib64/libgcc_s.so.1 Core was generated by `/usr/sbin/slapd -h ldap:/// -u ldap'. Program terminated with signal 6, Aborted. #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 #3 0x00000037a4e6da07 in malloc_consolidate () from /lib64/libc.so.6 #4 0x00000037a4e6f1fb in _int_free () from /lib64/libc.so.6 #5 0x00000037a4e72a6c in free () from /lib64/libc.so.6 #6 0x00000037a4ecabda in __vsyslog_chk () from /lib64/libc.so.6 #7 0x00000037a4ecaf33 in __syslog_chk () from /lib64/libc.so.6 #8 0x0000000000437869 in slapd_remove () #9 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #10 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 (gdb) Wolfgang Hummel

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by quanah＠zimbra.com 23 Mar '10

23 Mar '10

--On Monday, March 22, 2010 9:00 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > As already noted, there is no need to give root access to admins. My > guess is you really do not understand how ACLs work. I would advise > carefully reading the slapd-access(5) man page. You may also find a page I wrote some time ago useful in helping to understand how ACLs work: <http://www.stanford.edu/services/directory/openldap/configuration/slapd-acl…> Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by quanah＠zimbra.com 23 Mar '10

23 Mar '10

--On Monday, March 22, 2010 12:41 PM +0000 kean.johnston(a)gmail.com wrote: >> Authorization is the job of the ACL engine. Putting ad-hoc rules into >> user entries is, in a word, stupid. It's also unscaleable and will >> become an administration nightmare. > Well OK then. Using a configuration mechanism like ACL's that cannot be > distributed to multiple users (like editing a directory can) is, in a > word, stupid. It is also unscaleable and will become an administration > nightmare. And authorisation is not (or SHOULD not be) the job of ACL's > its the job of authorisation modules, which nssov is. > > Being forced to give admins who simply want to be able to change access > to a random host in a centralised server root access to what may be a > critical server with other sensitive data on it is simply wrong. As already noted, there is no need to give root access to admins. My guess is you really do not understand how ACLs work. I would advise carefully reading the slapd-access(5) man page. Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6481) Asssert with acl-sets and referals
by masarati＠aero.polimi.it 22 Mar '10

22 Mar '10

Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6490) dds and pcache overlays not checking NULL value
by masarati＠aero.polimi.it 22 Mar '10

22 Mar '10

Fixed (slighlty differently) in HEAD. Please test. Thanks, p.

1 0

(ITS#6497) Infinite loop in translucent.c
by ondrej.kuznik＠acision.com 22 Mar '10

22 Mar '10

Full_Name: Ondrej Kuznik Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Hi, there is a bug in translucent.c:208 in translucent_cf_gen such that modification of olcTranslucentRemote or olcTranslucentLocal can trigger an infinite loop, making the server unresponsive. Please see the attached patch that fixes the issue and consider including it in your codebase: --- servers/slapd/overlays/translucent.c 2009-11-30 12:59:06.000000000 +0100 +++ servers/slapd/overlays/fixed.c 2010-03-22 16:23:39.000000000 +0100 @@ -205,7 +205,7 @@ i = c->valx; ch_free( (*an)[i].an_name.bv_val ); do { - (*an)[i] = (*an)[i+1]; + (*an)[i] = (*an)[++i]; } while ( !BER_BVISNULL( &(*an)[i].an_name )); } return 0;

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> So let them edit the host permissions. Delegate the privileges to > groups, and give them write access to their respective groups. ... > Irrelevant. Using slapd.conf doesn't preclude delegation of privileges > or dynamic updates to privilege memberships. I have read the admin guide from cover to cover, several times. I am not an LDAP expert (yet) so perhaps some things you take for granted are not obvious to the newcomer. Everything I have read just makes me confused about how the above can work. If you can point me at a relevant place in teh the man pages, or the admin guide, or an example of how this is possible, I will both be very grateful and have a deeper understanding of why this patch isn't necessary. The documentation says: Authorization is checked by performing an LDAP Compare operation looking for the PAM service name in the authorizedService attribute. slapd ACLs should be set to grant or deny Compare privilege to the appropriate users or groups as desired. As the OpenLDAP architect and someone who has been using LDAP for decades, that may seem obvious to you. It is not to others. As I understand that to mean, I would have to have something like: access to dn.exact="cn=host1,ou=hosts,dc=example,dc=com" attrs=authroizedService by dn="uid=user1,ou=people,dc=example,dc=com" compare by dn=uid=user2,ou=people,dc=example,dc=com" compare by group.exact="cn=somegroup,ou=groups,dc=example,dc=com" compare by * none which is how I would give access to a group of people as well as individuals. Now I want to grant special access to user3, who isn't part of any particular group, just a random user who needs access to the host. Now I have to change the above ACL. That ACL is in slapd.conf. How to I delegate being able to give a non-root user permissions to add user3 to that host. How do I delegate a non-root user to set permissions for host2 and host 3 etc. I realise this may be incorrect but thats how I understand the docs. I am not particularly dumb so if thats what I took away from the docs, chances are others did too, and at best, the documentation needs beefing up. > On the contrary - for security management, it's the BEST thing. Keeping > your authorization rules scattered across the data space not only makes > it harder to administer, it also makes it easier to subvert. Keeping it > all isolated in a single administrative space negates both of those > problems. Clearly you have never worked in an organisation with several tens or even hundreds of thousands of users. I don't see how putting everything in the one place helps at all. In fact it makes it a bottleneck of the worst kind. But being able to partition things and giving team A responsibility over access to this group of hosts and team B responsibility over that group of hosts and having the host access and authorization information actually be in the host entry just makes more sense, and it scales better.

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by hyc＠symas.com 22 Mar '10

22 Mar '10

Kean Johnston wrote: >> This patch was rejected. The functionality it offered was already >> provided by the slapd ACL engine. > Could I ask you to reconsider your position on using ACL's? Using ACL's for > this kind of thing is a little bit like asking the security guard that > makes your entry badge also be in charge of all of your HR data and > documents. I understand the ACL engine may be quick but it completely > defeats the purpose of having a centralised directory. No, doing anything else defeats that purpose. > What if I want > directory administrators to be able to edit host permissions but I don't > want them to have root so they can edit slapd.conf or change the SLAPD > configuration? So let them edit the host permissions. Delegate the privileges to groups, and give them write access to their respective groups. > what if I cant even use the modern configuration because > overlays I want to use don't support it and I am forced to use slapd.conf? Irrelevant. Using slapd.conf doesn't preclude delegation of privileges or dynamic updates to privilege memberships. > It also moves away from the model of having data about the host in one dn: > cn=host,dc=example,dc=com entry to now having pretty vital information > about the host moved completely out of the directory itself and into the > directory server's configuration. That surely can't be a good thing. On the contrary - for security management, it's the BEST thing. Keeping your authorization rules scattered across the data space not only makes it harder to administer, it also makes it easier to subvert. Keeping it all isolated in a single administrative space negates both of those problems. The key to scalable security is centralized control with distributed access, not distributed control. The more widely you distribute the actual points of control, the more likely you are to make a mistake and open a hole between the points. > What if I want to move from OpenLDAP to some other server? Then you probably should be using nss-pam-ldapd, and not nssov. -- -- 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#6495) nssov patch to better emulate pam_ldap behaviour
by hyc＠symas.com 22 Mar '10

22 Mar '10

Kean Johnston wrote: >> Authorization is the job of the ACL engine. Putting ad-hoc rules into >> user entries is, in a word, stupid. It's also unscaleable and will >> become an administration nightmare. > Well OK then. Using a configuration mechanism like ACL's that cannot be > distributed to multiple users (like editing a directory can) is, in a word, > stupid. It is also unscaleable and will become an administration nightmare. > And authorisation is not (or SHOULD not be) the job of ACL's its the job of > authorisation modules, which nssov is. > > Being forced to give admins who simply want to be able to change access to > a random host in a centralised server root access to what may be a critical > server with other sensitive data on it is simply wrong. You seem to be laboring under the false premise that root privileges are required to administer authorization in slapd. Since that is false, the rest of your statements are moot. >> The user host attribute functionality is deprecated. I have no desire to >> make it even vaguely appear to be useful. > Then don't sell it as one. You claim pam_ldap compatibility but that is > false. The user docs also aren't nearly as strongly worded, saying that the > hostserver and ACL's is preferable, not that userhost is deprecated. > A flexible solution gives administrators the opportunity to use the tool in > ways you haven't conceived of because it works for them and their > environment. A ridgid and dictatorial tool forces people to do things one > way and one way only. I have worked for one of the larger software > companies and can tell you that the ACL mechanism would scale orders of > magnitude worse, and they did, in fact have authorisation info stored in > user and host attributes because that was the only way to delegate > responsibility to multiple groups. That may have been true of that other software package. That is not true here. > PS, you may wanna consider dropping the Ulrich Drepper attitude. When a > contributor, especially a first time one, who has gone to considerable > lengths to follow all the guidelines and do things just your way has, as > his first experience someone calling things "stupid" ... well, that will > thin the development herd considerably. No, I should rather step it up a notch. I don't want contributions from J. Random Developer. I want contributions from people who participate in the community. That means reading up on how things are done, following the established practices, and demonstrating a familiarity with the way things are done and establishing a familiarity with the other community members. That means showing that you'll take the time to stick around and continue to maintain/support your code if we pull it in. If a developer won't put that time in up front, then I don't care how good their code is; I don't want to be saddled with it when they inevitably disappear. The established practice for contributing new code is to discuss it on the openldap-devel mailing list first, before spending any time on actual coding. After the developer community gets a chance to think about it and weigh in on whether it's a good idea or not, then you start (or don't start) writing the code and submitting to the ITS. -- -- 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#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> Authorization is the job of the ACL engine. Putting ad-hoc rules into > user entries is, in a word, stupid. It's also unscaleable and will > become an administration nightmare. Well OK then. Using a configuration mechanism like ACL's that cannot be distributed to multiple users (like editing a directory can) is, in a word, stupid. It is also unscaleable and will become an administration nightmare. And authorisation is not (or SHOULD not be) the job of ACL's its the job of authorisation modules, which nssov is. Being forced to give admins who simply want to be able to change access to a random host in a centralised server root access to what may be a critical server with other sensitive data on it is simply wrong. > The user host attribute functionality is deprecated. I have no desire to > make it even vaguely appear to be useful. Then don't sell it as one. You claim pam_ldap compatibility but that is false. The user docs also aren't nearly as strongly worded, saying that the hostserver and ACL's is preferable, not that userhost is deprecated. A flexible solution gives administrators the opportunity to use the tool in ways you haven't conceived of because it works for them and their environment. A ridgid and dictatorial tool forces people to do things one way and one way only. I have worked for one of the larger software companies and can tell you that the ACL mechanism would scale orders of magnitude worse, and they did, in fact have authorisation info stored in user and host attributes because that was the only way to delegate responsibility to multiple groups. PS, you may wanna consider dropping the Ulrich Drepper attitude. When a contributor, especially a first time one, who has gone to considerable lengths to follow all the guidelines and do things just your way has, as his first experience someone calling things "stupid" ... well, that will thin the development herd considerably.

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> This patch was rejected. The functionality it offered was already > provided by the slapd ACL engine. Could I ask you to reconsider your position on using ACL's? Using ACL's for this kind of thing is a little bit like asking the security guard that makes your entry badge also be in charge of all of your HR data and documents. I understand the ACL engine may be quick but it completely defeats the purpose of having a centralised directory. What if I want directory administrators to be able to edit host permissions but I don't want them to have root so they can edit slapd.conf or change the SLAPD configuration? what if I cant even use the modern configuration because overlays I want to use don't support it and I am forced to use slapd.conf? It also moves away from the model of having data about the host in one dn: cn=host,dc=example,dc=com entry to now having pretty vital information about the host moved completely out of the directory itself and into the directory server's configuration. That surely can't be a good thing. What if I want to move from OpenLDAP to some other server? Kean

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by hyc＠symas.com 22 Mar '10

22 Mar '10

kean.johnston(a)gmail.com wrote: > Full_Name: Kean Johnston > Version: HEAD > OS: Linux (CentOS 5.3) > URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch > Submission from: (NULL) (196.210.34.161) > > > The nssov manual page states that some of it's options "duplicates the original > pam_ldap authorization behavior". However, they don't quite. pam_ldap has the > ability for you to use "wildcards" in a user's host: attribute. I say > "wildcards" in quotes because the pam_ldap implementation does not actually use > regex matching, but rather check for two special strings, "*" and "!". > > The ability to use actual wildcards, especially ones you can negate, on a per > user basis is extremely useful to an administrator of large networks. For > example you may want all developers to have access to the machines in > developers.mydomain.com but you want to disallow access to some of those > machines to contractors or interns. > > This patch allows such behaviour, so it serves the dual purpose of actually > implementing existing pam_ldap behaviour in case people already depend on that, > as well as extends it to be a more generally usable feature by using actual > regular expressions. The code is simple, and the man page change describes it > well enough. Please consider adding this code to nssov. Thank you. > Authorization is the job of the ACL engine. Putting ad-hoc rules into user entries is, in a word, stupid. It's also unscaleable and will become an administration nightmare. The user host attribute functionality is deprecated. I have no desire to make it even vaguely appear to be useful. -- -- 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#6487) Nssov pam_authz authorizedUserService
by hyc＠symas.com 22 Mar '10

22 Mar '10

kean.johnston(a)gmail.com wrote: > I like what this offers administrators but I have a comment about how you > handle "wildcards". They aren't wild at all, but "magic strings" with only > one possible meaning: all users/services with the single magic character > "*". If you have a defined user naming convention like i_whatever for > interns and c_whatever for contractors, it would be useful to be able to > either include or exclude such users from using certain services. > > My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for > userhost and userservices attributes, and includes negation. Would you be > interested in working with me to expand this to support real wildcards? > Also I suggest you make this two patches, as the patch submission > guidelines clearly state that one patch for 1 feature, and the meaty parts > of this are obfuscated by increasing the buffer sizes which should probably > be in a separate patch. > > Regards, Kean This patch was rejected. The functionality it offered was already provided by the slapd ACL engine. -- -- 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#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

I like what this offers administrators but I have a comment about how you handle "wildcards". They aren't wild at all, but "magic strings" with only one possible meaning: all users/services with the single magic character "*". If you have a defined user naming convention like i_whatever for interns and c_whatever for contractors, it would be useful to be able to either include or exclude such users from using certain services. My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for userhost and userservices attributes, and includes negation. Would you be interested in working with me to expand this to support real wildcards? Also I suggest you make this two patches, as the patch submission guidelines clearly state that one patch for 1 feature, and the meaty parts of this are obfuscated by increasing the buffer sizes which should probably be in a separate patch. Regards, Kean

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

ftp.openldap.org reports no space on the device, so the URL for the patch is at: http://64.34.163.232/openldap/kean-johnston-100321.patch

1 0

(ITS#6496) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

Full_Name: Kean Johnston Version: HEAD OS: Linux (CentOS 5.3) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch Submission from: (NULL) (196.210.34.161) The nssov manual page states that some of it's options "duplicates the original pam_ldap authorization behavior". However, they don't quite. pam_ldap has the ability for you to use "wildcards" in a user's host: attribute. I say "wildcards" in quotes because the pam_ldap implementation does not actually use regex matching, but rather check for two special strings, "*" and "!". The ability to use actual wildcards, especially ones you can negate, on a per user basis is extremely useful to an administrator of large networks. For example you may want all developers to have access to the machines in developers.mydomain.com but you want to disallow access to some of those machines to contractors or interns. This patch allows such behaviour, so it serves the dual purpose of actually implementing existing pam_ldap behaviour in case people already depend on that, as well as extends it to be a more generally usable feature by using actual regular expressions. The code is simple, and the man page change describes it well enough. Please consider adding this code to nssov. Thank you.

1 0

(ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

Full_Name: Kean Johnston Version: HEAD OS: Linux (CentOS 5.3) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch Submission from: (NULL) (196.210.34.161) The nssov manual page states that some of it's options "duplicates the original pam_ldap authorization behavior". However, they don't quite. pam_ldap has the ability for you to use "wildcards" in a user's host: attribute. I say "wildcards" in quotes because the pam_ldap implementation does not actually use regex matching, but rather check for two special strings, "*" and "!". The ability to use actual wildcards, especially ones you can negate, on a per user basis is extremely useful to an administrator of large networks. For example you may want all developers to have access to the machines in developers.mydomain.com but you want to disallow access to some of those machines to contractors or interns. This patch allows such behaviour, so it serves the dual purpose of actually implementing existing pam_ldap behaviour in case people already depend on that, as well as extends it to be a more generally usable feature by using actual regular expressions. The code is simple, and the man page change describes it well enough. Please consider adding this code to nssov. Thank you.

1 0

(ITS#6494) replication doesn't works if directory contains more than one tree
by Ikonta＠yandex.ru 19 Mar '10

19 Mar '10

Full_Name: Sergey A. Starikov Version: 2.4.21 OS: FreeBSD 7.2-RELEASE-p4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.229.208.12) Also (currently the main OS) is FreeBSD 6.4-RELEASE-p9. Configuration stored in slapd.conf. Two servers in mirror mode. The slapd.conf is: <includes> serverID pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb <ACLs set (replicator user can read everything in replicated tree)> sizelimit 1024 # ####################################################################### # BDB database definitions ####################################################################### # db #1 (caotus userbase, main database) database bdb suffix "dc=mydomain,dc=ru" rootdn "uid=admin,dc=mydomain,dc=ru" rootpw {SSHA}<some hash> overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/db/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub <and some other indexes> # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=002 provider=ldap://ldapN.mydomain.ru:389 type=refreshOnly interval=00:00:12:00 retry="64 16 256 4" searchbase="dc=mydomain,dc=ru" scope=sub sizelimit=unlimited timelimit=512 schemachecking=on bindmethod=simple binddn="uid=Replicator,ou=People,dc=mydomain,dc=ru" credentials=secret mirrormode on # db #2 (ESPP certs database accesslog) database bdb suffix "cn=accesslog" # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/log/openldap-accesslog # Indices to maintain index reqStart eq In described case accesslog overlay works normally. But overlay syncprov is _particularly_ inoperate (transferred only one of about 28 changes in source database). Both in refreshAndPersist and refreshOnly replication modes. If I remove the accesslog overlay from slapd.conf --- replication works as it should. Also, if I try to add instead the accesslog another tree, for example: slapd.conf: ... # db #2 database bdb suffix "dc=public,dc=org" directory /var/db/openldap-db2 # Indices to maintain index objectClass eq <other indexes> ... replication also doesn't works.

1 0

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

18 Mar '10

On 3/17/2010 9:25 PM, Quanah Gibson-Mount wrote: > --On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > >> tjoen wrote: >>> 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.* ? >>> >> >> No, they do not get sent to local4.* - the only TLS message which makes >> it there in this scenario is: slapd[72041]: main: TLS init def ctx >> failed: -1 >> >> Like I said, the ONLY way to get the actual TLS error messages is to run >> the daemon by hand in the foreground with loglevel stats by way of >> 'slapd >> -d stats'. Per the manpage this also prevents slapd from forking: >> -d debug-level >> Turn on debugging as defined by debug-level. If this >> option is specified, even with a zero argument, slapd >> will not fork or disassociate from the invoking >> terminal. >> >> >> Let me know if I'm still not being clear. > > If you are trying to debug an issue, you most certainly should be > running slapd -d <level>... that's why it exists. > > --Quanah > That's a valid point. However, it does not explain why the TLS errors aren't (or "shouldn't be") logged via syslog.

1 0

Re: (ITS#6493) Broken link in online openldap administrator's guide
by ghenry＠OpenLDAP.org 18 Mar '10

18 Mar '10

----- "felix wolfsteller" <felix.wolfsteller(a)intevation.de> wrote: > Full_Name: Felix Wolfsteller > Version: n/a > OS: na/a > URL: http://www.openldap.org/doc/admin24/schema.html > Submission from: (NULL) (212.95.107.190) > > > In the online openldap administrator's guide, section 13.2.1 > ( http://www.openldap.org/doc/admin24/schema.html ) > , > > " http://www.alvestrand.no/harald/objectid/ " > > is referenced, where it should be > > " http://www.alvestrand.no/objectid/ " , i guess. Thanks, will fix. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6493) Broken link in online openldap administrator's guide
by felix.wolfsteller＠intevation.de 18 Mar '10

18 Mar '10

Full_Name: Felix Wolfsteller Version: n/a OS: na/a URL: http://www.openldap.org/doc/admin24/schema.html Submission from: (NULL) (212.95.107.190) In the online openldap administrator's guide, section 13.2.1 ( http://www.openldap.org/doc/admin24/schema.html ) , " http://www.alvestrand.no/harald/objectid/ " is referenced, where it should be " http://www.alvestrand.no/objectid/ " , i guess.

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by quanah＠zimbra.com 18 Mar '10

18 Mar '10

--On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > tjoen wrote: >> 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.* ? >> > > No, they do not get sent to local4.* - the only TLS message which makes > it there in this scenario is: slapd[72041]: main: TLS init def ctx > failed: -1 > > Like I said, the ONLY way to get the actual TLS error messages is to run > the daemon by hand in the foreground with loglevel stats by way of 'slapd > -d stats'. Per the manpage this also prevents slapd from forking: > -d debug-level > Turn on debugging as defined by debug-level. If this > option is specified, even with a zero argument, slapd > will not fork or disassociate from the invoking > terminal. > > > Let me know if I'm still not being clear. If you are trying to debug an issue, you most certainly should be running slapd -d <level>... that's why it exists. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by quanah＠zimbra.com 18 Mar '10

18 Mar '10

--On Tuesday, March 16, 2010 8:31 PM +0000 robert.hanson(a)calabrio.com wrote: > Full_Name: Robert Hanson > Version: 2.4.21 > OS: RedHat 4.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.203.208.250) > > > 1) start with an empty database; use slapadd to add a large (3 MB) > database. 2) Use ldapbrowser to delete nearly all the nodes. After this > process, I get to a point where a subnode can't be deleted; I see the > message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center > 1, ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed] > 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, > ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser > window. > > Steps to reproduce: (on redhat linux; I think any linux will do) > 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the > distro. 2) copy built slapd to an appropriate place. link it to slapadd. > 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is > scheduled to close 3/23/2010; let me know if you need the file uploaded > again). unzip the file, it contains the slapcat.out; a blank database > (in a subfolder), and a slapd.conf file. > 4) Edit the slapd.conf file as needed to point to the directory where you > put the database. > > That was the setup, now here are the steps to reproduce the problem: > > 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. > 6) start slapd (using slapd -d 1 -f slapd.conf) > 7) use ldapbrowser to delete the "lcc=call center 1" node. > > It takes a long time, but eventually you'll see it fail while trying to > delete the "agents" node. > Do you see this problem using BDB 4.7.25+patches instead of BDB 4.8? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

17 Mar '10

tjoen wrote: >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.* ? > No, they do not get sent to local4.* - the only TLS message which makes it there in this scenario is: slapd[72041]: main: TLS init def ctx failed: -1 Like I said, the ONLY way to get the actual TLS error messages is to run the daemon by hand in the foreground with loglevel stats by way of 'slapd -d stats'. Per the manpage this also prevents slapd from forking: -d debug-level Turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slapd will not fork or disassociate from the invoking terminal. Let me know if I'm still not being clear.

1 0

(ITS#6492) sendmail+openldap
by exclusivedesign＠yandex.ru 17 Mar '10

17 Mar '10

Full_Name: Leo Version: openldap-sasl-client-2.4.21 OS: freebsd 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.247.195.163) Hello. I use ldap_routing feature in the sendmail (8.14.4). When I upgrade openldap from 2.4.19 to 2.4.21, ldap routing stopped working. SYSERR(root): Error getting LDAP results in map ldapmra: Partial results and referral received downgrade to old version - not helped. Help me please.

1 0

(ITS#6491) LDAP Error code 80 - Dn index delete failed
by robert.hanson＠calabrio.com 16 Mar '10

16 Mar '10

Full_Name: Robert Hanson Version: 2.4.21 OS: RedHat 4.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.203.208.250) 1) start with an empty database; use slapadd to add a large (3 MB) database. 2) Use ldapbrowser to delete nearly all the nodes. After this process, I get to a point where a subnode can't be deleted; I see the message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed] 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser window. Steps to reproduce: (on redhat linux; I think any linux will do) 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the distro. 2) copy built slapd to an appropriate place. link it to slapadd. 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is scheduled to close 3/23/2010; let me know if you need the file uploaded again). unzip the file, it contains the slapcat.out; a blank database (in a subfolder), and a slapd.conf file. 4) Edit the slapd.conf file as needed to point to the directory where you put the database. That was the setup, now here are the steps to reproduce the problem: 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. 6) start slapd (using slapd -d 1 -f slapd.conf) 7) use ldapbrowser to delete the "lcc=call center 1" node. It takes a long time, but eventually you'll see it fail while trying to delete the "agents" node.

1 0

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

15 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. Well, if a shadow uses slapo-chain(5), the producer must be configured in order to allow writes coming from the shadow. >> > 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? Not in the original code. In that case, the modification was bypassing replication, thus it was being applied to the shadow without generating a referral. The alternative, inconsistent solution you seem to indicate would require to replay the modification as internal in case the modification to the producer failed because the service was not available. > 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. We should bring this to -devel, to see whether it makes sense and whether it would be acceptable. p.

1 0

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

15 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 15 Mar '10

15 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 07 Mar '10

07 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 06 Mar '10

06 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 06 Mar '10

06 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 04 Mar '10

04 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 03 Mar '10

03 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 02 Mar '10

02 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs