openldap-bugs

openldap-bugs@openldap.org

1 participants
20954 discussions

Re: (ITS#4829) slapd-config should create olcDbDirectory
by hyc＠symas.com 18 Feb '07

18 Feb '07

ghenry(a)suretecsystems.com wrote: > In another step towards 100% remote admin/config, could we store StartTLS > certs in the directory for slapd usage, replacing the need for: > > TLS* config path hardcoding.? One step at a time... Ordinarily I would store certs in an entry with the same DN as the cert. This would mean creating a directory entry for your server name, as well as directory entries for any client certs you wanted to use. That's probably not the ideal way to go here. We could store the certs directly, in attributes under cn=config. We could also just store DNs in the config attributes, pointing to certs in some other database entries. -- -- Howard Chu Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 18 Feb '07

18 Feb '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="Howard Chu"> >> ghenry(a)suretecsystems.com wrote: >> >>> Dear All, >>> >>> If we are to suppose that slapd-config is to provide 100% remote >>> configuration, >>> then directories should be created as set in: >>> >>> olcDbDirectory >>> set_lg_dir >>> >>> >>> Questions/Needs: >>> >>> 1. How to handle existing directories on mkdir? >>> 2. Some global cn=config setting to say what cn=config is allowed to do >>> 3. Plus many more I'm sure. >> >> Some of this touches on issues raised in ITS#4535. We probably need to >> answer >> those points first. > > Understood. > In another step towards 100% remote admin/config, could we store StartTLS certs in the directory for slapd usage, replacing the need for: TLS* config path hardcoding.? Gavin.

1 0

(ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 17 Feb '07

17 Feb '07

Full_Name: Gavin Henry Version: 2.3.34/2.4.4alpha OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Just a quick to note that there are some overlays missing from slapd.overlays.5 in 2.4.4alpha and actual man pages. Also, relay and rwm are still marked as experimental in some places. grep experimental doc/man/man5/* doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay are experimental. doc/man/man5/slapo-rwm.5:This overlay is experimental. I'll help where I can, Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 17 Feb '07

17 Feb '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: > >> Dear All, >> >> If we are to suppose that slapd-config is to provide 100% remote >> configuration, >> then directories should be created as set in: >> >> olcDbDirectory >> set_lg_dir >> >> >> Questions/Needs: >> >> 1. How to handle existing directories on mkdir? >> 2. Some global cn=config setting to say what cn=config is allowed to do >> 3. Plus many more I'm sure. > > Some of this touches on issues raised in ITS#4535. We probably need to > answer > those points first. Understood. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > Chief Architect, OpenLDAP http://www.openldap.org/project/ >

1 0

ITS#4535 back-config can allow break-ins
by hyc＠symas.com 17 Feb '07

17 Feb '07

The first issue here was in regards to protection for the config backend when running the tests in the test suite. That was addressed mainly by using a randomly generated rootpw for cn=config in all of the tests. Also the default ACL for the config backend is explicitly set to "access to * by * none". In terms of the potential attacks on a server through back-config - it's obvious to me that you have to treat access to back-config the same as you would treat SSH credentials for a root user on the machine. That was one of the main reasons I decided to make cn=config only usable by its rootdn in 2.3. But since you really should be able to delegate authority, we added regular ACL support for 2.4. So it still comes down to having sane ACLs configured. Most of the attacks listed here require a user to have shell access to the machine, and write access to relevant filesystems. Frankly I think these attack scenarios are contrived - if you have untrusted users logging in to your system, you have other problems already. re: a meta-config file - No. The design goal here is to remove all limitations that prevent totally remote administration of the server, not add new ones. Artificial restrictions, just like artificially restricting 2.3 to rootdn only, will only impair usability and eventually get removed. re: lstat/fstat to prevent use of symlinks - No. There are too many valid uses for symlinks. What might make sense would be to fstat targets and check that they are owned by the current user and are not world-writable. We might also include root-owned directories that are world-writable with the sticky bit set. re: Documentation - sure. re: slaptools with -r/-u/-g - That's been discussed in ITS#4719. The consensus there seems (to me) to be that people with root access better know wth they're doing. re: adding dangerous database configurations - this raises a question about the config DIT. It implies a need for individual containers for backends, databases, and modules, so that you can configure write access to their children attribute. Otherwise, at the moment, we have no way to give fine grained access as to who can create what entries. The other alternative is to make back-config's add handler check for wadd access to the objectclass attribute of new entries, which would be oddly inconsistent with regular backend behavior. I specifically omitted such containers in the original DIT because I assumed only a rootDN, and with the object types essentially coded into their RDNs, the containers were superfluous. I still consider such containers redundant, and would lean toward the objectclass ACL check, which we can also make value-dependent to control exactly what types of databases an administrator can add. Assuming we have fine-grain control over what databases can be added, there should be no further consideration of whether to allow back-passwd, back-perl, or whatever. If an authorized admin wants to add them, let them. Fine-grained restriction of modules is pretty much irrelevant - all we have to go on is a name, which need not bear any relation to the module's actual content. The best we can do here is check ownership, as with other path-related items. re: Can one add "some-attribute:< file:///foobar" over the protocol to a back-ldif database to read file /foobar? I don't think so, but...? No. The URL is processed by the LDIF reader, which in this case is the client. At this point we should probably split this ITS into a few different ones. The main point, vulnerability in the test suite, has already been addressed. The doc-related issues obviously should go to a Doc bug. That leaves path ownership/permission checking for one bug, and fine-grained control of Adds as a separate bug. -- -- Howard Chu Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by hyc＠symas.com 17 Feb '07

17 Feb '07

ghenry(a)suretecsystems.com wrote: > Dear All, > > If we are to suppose that slapd-config is to provide 100% remote configuration, > then directories should be created as set in: > > olcDbDirectory > set_lg_dir > > > Questions/Needs: > > 1. How to handle existing directories on mkdir? > 2. Some global cn=config setting to say what cn=config is allowed to do > 3. Plus many more I'm sure. Some of this touches on issues raised in ITS#4535. We probably need to answer those points first. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Leaks from test050 in re24
by Pierangelo Masarati 15 Feb '07

15 Feb '07

I see some small leaks in test050; I'm posting valgrind's output below, unfortunately I have no time to investigate them right now. p. ==23984== 71,251 (5,744 direct, 65,507 indirect) bytes in 153 blocks are definitely lost in loss record 7 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821A879: ber_memrealloc_x (memory.c:307) ==23984== by 0x821B178: ber_bvreplace_x (memory.c:706) ==23984== by 0x80F5734: slap_queue_csn (ctxcsn.c:168) ==23984== by 0x80F582D: slap_get_csn (ctxcsn.c:191) ==23984== by 0x8088AE3: slap_add_opattrs (add.c:601) ==23984== by 0x8123546: ldif_back_add (ldif.c:799) ==23984== by 0x806C426: config_setup_ldif (bconfig.c:3495) ==23984== by 0x806C7CD: read_config (bconfig.c:3573) ==23984== by 0x80622ED: main (main.c:747) ==23984== 65,507 bytes in 497 blocks are indirectly lost in loss record 8 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821ABD7: ber_dupbv_x (memory.c:504) ==23984== by 0x80C5A80: objectClassPretty (schema_prep.c:100) ==23984== by 0x80A09D6: ordered_value_pretty (value.c:496) ==23984== by 0x809BACA: slap_mods_check (modify.c:577) ==23984== by 0x8087AD0: do_add (add.c:160) ==23984== by 0x807F866: connection_operation (connection.c:1129) ==23984== by 0x807FD33: connection_read_thread (connection.c:1257) ==23984== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==23984== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==23984== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24033== 183 (60 direct, 123 indirect) bytes in 6 blocks are definitely lost in loss record 5 of 7 ==24033== at 0x4004405: malloc (vg_replace_malloc.c:149) ==24033== by 0x821A75F: ber_memalloc_x (memory.c:226) ==24033== by 0x821A7B2: ber_memalloc (memory.c:242) ==24033== by 0x809FB6C: value_add_one (value.c:96) ==24033== by 0x80F5EFC: slap_parse_sync_cookie (ldapsync.c:238) ==24033== by 0x81CD1EA: syncprov_parseCtrl (syncprov.c:2768) ==24033== by 0x80B7266: slap_parse_ctrl (controls.c:580) ==24033== by 0x80B7A0D: get_ctrls (controls.c:749) ==24033== by 0x80822C2: do_search (search.c:165) ==24033== by 0x807F866: connection_operation (connection.c:1129) ==24033== by 0x807FD33: connection_read_thread (connection.c:1257) ==24033== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24033== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24033== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24000== 70,778 (5,176 direct, 65,602 indirect) bytes in 142 blocks are definitely lost in loss record 8 of 9 ==24000== at 0x40056BF: calloc (vg_replace_malloc.c:279) ==24000== by 0x821A7F0: ber_memcalloc_x (memory.c:280) ==24000== by 0x809F775: ch_calloc (ch_malloc.c:104) ==24000== by 0x8088695: slap_mods2entry (add.c:472) ==24000== by 0x80E8A14: syncrepl_message_to_entry (syncrepl.c:1723) ==24000== by 0x80E5840: do_syncrep2 (syncrepl.c:790) ==24000== by 0x80E6C23: do_syncrepl (syncrepl.c:1164) ==24000== by 0x807FD51: connection_read_thread (connection.c:1259) ==24000== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24000== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24000== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so)

1 0

Re: (ITS#4420) Hanging CLOSE_WAIT connections in ldap-backend
by aar＠cpan.org 15 Feb '07

15 Feb '07

I'm experiencing the CLOSE_WAIT problem with slapd 2.3.32 on MacOS X (PPC). Cached connections aren't being leaked but they aren't closed on idle-timeout and they remain in CLOSE_WAIT state after the remote host has gone. Compile options: ./configure --enable-rewrite --enable-ldap --enable-meta --enable-proxycache --enable-spasswd slapd.conf: =========== database ldap suffix "dc=AddressBooks,dc=example,dc=com" uri ldap://localhost:8080 idle-timeout 2 idassert-bind bindmethod=none binddn="cn=Administrative Identity,dc=sssss" credentials="admin_password" authzID="dn:cn=Sandbox,dc=local,dc=example,dc=com" mode=self authz=proxyAuthz (The problem appears also without idle-timeout.) Steps to reproduce: 1. start slapd 2. connect to slapd and do some queries 3. disconnect the proxied server (for example by killing it) 4. netstat -a still shows the connection as CLOSE_WAIT Debug: when running slapd with "-d 5", nothing is printed when the connection is closed by the remote host (i.e. when I kill it), so slapd isn't probably catching the event at all. - alessandro ranellucci.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by hyc＠symas.com 14 Feb '07

14 Feb '07

ahasenack(a)terra.com.br wrote: > On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >> symbol lookup error: >> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >> ldap_back_proxy_authz_ctrl > > Howard debugged this on IRC and it turns out that our (mine and > _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd > without the unixodbc lib fixes it. Yes, so there are two potential issues - the unixodbc shared library seems to be statically linked with an older version of libltdl. I didn't run into this problem on my build because I don't have that odbc library. Anyway, due to the link order of the libraries, the lt_dlopen in this library gets used before the linker resolves to the system's libltdl.so, and it seems that this version of lt_dlopen doesn't automatically export the symbols of modules that it loads. I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is because there is a new dependency in 2.3.33 between back-meta and back-ldap. The other part of this is that the slapd binary should not be getting linked against -lodbc when back_sql is built as a module. Although, if back-sql is built statically, and other backends are dynamic, this problem may still crop up. It seems that fixing -lodbc would be required then. -- -- Howard Chu Chief Architect, 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#4830) test030-relay fails with back-meta
by ahasenack＠terra.com.br 14 Feb '07

14 Feb '07

On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: > ==> rewrite_context_apply [depth=1] string='(objectClass=*)' > ==> rewrite_context_apply [depth=1] res={0,'NULL'} > [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" > /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: > symbol lookup error: > +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: > ldap_back_proxy_authz_ctrl Howard debugged this on IRC and it turns out that our (mine and _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd without the unixodbc lib fixes it.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs