openldap-bugs July 2008

openldap-bugs@openldap.org

43 participants
131 discussions

(ITS#5606) Attempt to close unopened sockets when daemon doesn't run as a daemon
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the first. Because slapd_daemon_destroy can be called without slapd_deamon_init being called (e.g. if testing configuration, or giving -VV as the documentation suggests does something, though I'm not sure what), an attempt can be made to close sockets not opened. I suggest the following fix: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -79,7 +79,7 @@ #define SLAPD_LISTEN_BACKLOG 1024 #endif /* ! SLAPD_LISTEN_BACKLOG */ -static ber_socket_t wake_sds[2]; +static ber_socket_t wake_sds[2] = {INVALID_SOCKET, INVALID_SOCKET}; static int emfile; static volatile int waking; @@ -1641,8 +1643,10 @@ slapd_daemon_destroy( void ) { connections_destroy(); - tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); - tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); + if ( wake_sds[1] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); + if ( wake_sds[0] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); sockdestroy(); #ifdef HAVE_SLP I couldn't find this mentioned in your tracker already.

1 0

(ITS#5605) Inappropriate SLAP_SOCK_NOT_ACTIVE assertion failing
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. While debugging to find and fix two crashes which I will detail in other posts, I discovered that an assertion is always failing because it seems it is inappropriately included when it shouldn't be. I suggest this patch. diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -829,7 +829,9 @@ { ldap_pvt_thread_mutex_lock( &slap_daemon.sd_mutex ); +#if defined(HAVE_EPOLL) assert( SLAP_SOCK_NOT_ACTIVE(s) ); +#endif if ( isactive ) slap_daemon.sd_nactives++; If you search for where the relevant parts of the macros involved in SLAP_SOCK_NOT_ACTIVE, and particularly the marking of active and inactive, I believe you will find they apply only in the HAVE_EPOLL case, and thus the assertion should only hold in that case. I did find a closed issue in your tracker related to the same assertion failing, but it didn't detail the fix, and was very old, so I assume was not relevant to this particular problem.

1 0

(ITS#5604) sbin executable names not recognised on Win32
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. In so doing, I discovered the following platform-specific issue. The executables on Win32 have a .exe extension, so slapd does not detect the tool names and act accordingly. Consequently, slapadd, slaptest, etc. all act the same as slapd! I solved the problem by patching main.c as follows: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/main.c openldap/servers/slapd/main.c --- openldap-2.4.10/servers/slapd/main.c 2008-05-20 10:10:40.000000000 +1000 +++ openldap/servers/slapd/main.c 2008-06-28 21:56:09.000000000 +1000 @@ -71,14 +71,14 @@ char *name; MainFunc *func; } tools[] = { - {"slapadd", slapadd}, - {"slapcat", slapcat}, - {"slapdn", slapdn}, - {"slapindex", slapindex}, - {"slappasswd", slappasswd}, - {"slaptest", slaptest}, - {"slapauth", slapauth}, - {"slapacl", slapacl}, + {"slapadd.exe", slapadd}, + {"slapcat.exe", slapcat}, + {"slapdn.exe", slapdn}, + {"slapindex.exe", slapindex}, + {"slappasswd.exe", slappasswd}, + {"slaptest.exe", slaptest}, + {"slapauth.exe", slapauth}, + {"slapacl.exe", slapacl}, /* NOTE: new tools must be added in chronological order, * not in alphabetical order, because for backwards * compatibility name[4] is used to identify the Obviously this exact fix is not appropriate, because it will break every other platform, but I am not sure of the appropriate preprocessor directive to use to address this, as I guess it would also break a cygwin build, and should only be done for a MinGW32 build. However, it would be helpful to fix with an appropriate conditional! I couldn't find a mention of this in your tracker so reporting it now.

1 0

(ITS#5603) Linking OpenSSL on Windows requires libgdi32 and libws2_32 after libcrypto
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

1 0

(ITS#5602) Windows ODBC library libodbc32 not found by configure
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users. Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process. I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer. This is the first. On Windows/MinGW, the ODBC library is not libodbc.a, but libodbc32.a. Furthermore, it seems the way function names are mangled on that platform includes their stack frame size: the symbol for SQLDriverConnect which configure tests for is _SQLDriverConnect@32. I got around this by manually changing -lodbc to -lodbc32 in configure and then further patching it as follows: diff -ru --exclude=Makefile openldap-2.4.10/configure openldap/configure --- openldap-2.4.10/configure 2008-02-12 10:36:45.000000000 +1100 +++ openldap/configure 2008-06-28 19:36:36.000000000 +1000 @@ -32018,11 +32018,14 @@ #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ -char SQLDriverConnect (); +/*char SQLDriverConnect ();*/ +#include <windows.h> +#include <sqlext.h> int main () { -SQLDriverConnect (); +/*SQLDriverConnect ();*/ +SQLDriverConnect (0,0,0,0,0,0,0,0); ; return 0; } This pulls in the appropriate headers for configure to find and use _SQLDriverConect@32 in libodbc32. I got part of the idea from another user's post I found on the Net, but a quick search of your issue tracker didn't show it up, so I am reporting it now. A more appropriate fix would be to change configure.in so that there are three checks for ODBC: one in libiodbc, one in libodbc and one in libodbc32, which is Windows specific, pulling in windows.h and sqlext.h before looking for the symbol with 8 arguments. I guess this would probably involve a more customised macro in configure.in. If that is too much trouble, perhaps the value for the ODBC library could just be assumed if configure can detect a Windows build.

1 0

A bunch of bugs the ITS seems to be ignoring
by Ben Schmidt 08 Jul '08

08 Jul '08

Hi, In late June I tried to submit 6 bug reports using your issue tracker online. They seemed to submit OK, but didn't show up straight away, however since you note on the site that they may not show up immediately, I was content to wait. They still haven't shown up, though. So now I have 7 bug reports! The original six are below. The seventh is that the issue tracker doesn't work, or requires login or something else that isn't documented. If someone knows what I was doing wrong with the tracker and can explain what I should be doing, I'm happy to enter these into it again more effectively. (My email program is likely to wrap this and thereby botch up the patches, too. They're probably still easy enough to understand/fix.) Ben. ------------------------------------------------------------------------ My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users. Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process. I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer. This is the first. On Windows/MinGW, the ODBC library is not libodbc.a, but libodbc32.a. Furthermore, it seems the way function names are mangled on that platform includes their stack frame size: the symbol for SQLDriverConnect which configure tests for is _SQLDriverConnect@32. I got around this by manually changing -lodbc to -lodbc32 in configure and then further patching it as follows: diff -ru --exclude=Makefile openldap-2.4.10/configure openldap/configure --- openldap-2.4.10/configure 2008-02-12 10:36:45.000000000 +1100 +++ openldap/configure 2008-06-28 19:36:36.000000000 +1000 @@ -32018,11 +32018,14 @@ #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ -char SQLDriverConnect (); +/*char SQLDriverConnect ();*/ +#include <windows.h> +#include <sqlext.h> int main () { -SQLDriverConnect (); +/*SQLDriverConnect ();*/ +SQLDriverConnect (0,0,0,0,0,0,0,0); ; return 0; } This pulls in the appropriate headers for configure to find and use _SQLDriverConect@32 in libodbc32. I got part of the idea from another user's post I found on the Net, but a quick search of your issue tracker didn't show it up, so I am reporting it now. A more appropriate fix would be to change configure.in so that there are three checks for ODBC: one in libiodbc, one in libodbc and one in libodbc32, which is Windows specific, pulling in windows.h and sqlext.h before looking for the symbol with 8 arguments. I guess this would probably involve a more customised macro in configure.in. If that is too much trouble, perhaps the value for the ODBC library could just be assumed if configure can detect a Windows build. ------------------------------------------------------------------------ My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users. Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process. I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer. This is the second. When linking OpenSSL on Windows, it is also necessary to link against libgdi32 and libws2_32 needs to be linked after libcrypto. I worked around the problem with a simple substitution in configure: s/-lcrypto/-lcrypto -lgdi32 -lws2_32 A more appropriate fix would be to make configure test first without these extra libraries, and then with them, so that they are included if needed. Note that configure will not fail if -lws2_32 is omitted, but building libldap and libldap_r will fail later. I think it is probably safe to assume that if -lgdi32 is needed, -lws2_32 will be (or at least available and not harmful to include). A quick search and I couldn't find this issue already in your tracker. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. In so doing, I discovered the following platform-specific issue. The executables on Win32 have a .exe extension, so slapd does not detect the tool names and act accordingly. Consequently, slapadd, slaptest, etc. all act the same as slapd! I solved the problem by patching main.c as follows: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/main.c openldap/servers/slapd/main.c --- openldap-2.4.10/servers/slapd/main.c 2008-05-20 10:10:40.000000000 +1000 +++ openldap/servers/slapd/main.c 2008-06-28 21:56:09.000000000 +1000 @@ -71,14 +71,14 @@ char *name; MainFunc *func; } tools[] = { - {"slapadd", slapadd}, - {"slapcat", slapcat}, - {"slapdn", slapdn}, - {"slapindex", slapindex}, - {"slappasswd", slappasswd}, - {"slaptest", slaptest}, - {"slapauth", slapauth}, - {"slapacl", slapacl}, + {"slapadd.exe", slapadd}, + {"slapcat.exe", slapcat}, + {"slapdn.exe", slapdn}, + {"slapindex.exe", slapindex}, + {"slappasswd.exe", slappasswd}, + {"slaptest.exe", slaptest}, + {"slapauth.exe", slapauth}, + {"slapacl.exe", slapacl}, /* NOTE: new tools must be added in chronological order, * not in alphabetical order, because for backwards * compatibility name[4] is used to identify the Obviously this exact fix is not appropriate, because it will break every other platform, but I am not sure of the appropriate preprocessor directive to use to address this, as I guess it would also break a cygwin build, and should only be done for a MinGW32 build. However, it would be helpful to fix with an appropriate conditional! I couldn't find a mention of this in your tracker so reporting it now. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. While debugging to find and fix two crashes which I will detail in other posts, I discovered that an assertion is always failing because it seems it is inappropriately included when it shouldn't be. I suggest this patch. diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -829,7 +829,9 @@ { ldap_pvt_thread_mutex_lock( &slap_daemon.sd_mutex ); +#if defined(HAVE_EPOLL) assert( SLAP_SOCK_NOT_ACTIVE(s) ); +#endif if ( isactive ) slap_daemon.sd_nactives++; If you search for where the relevant parts of the macros involved in SLAP_SOCK_NOT_ACTIVE, and particularly the marking of active and inactive, I believe you will find they apply only in the HAVE_EPOLL case, and thus the assertion should only hold in that case. I did find a closed issue in your tracker related to the same assertion failing, but it didn't detail the fix, and was very old, so I assume was not relevant to this particular problem. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the first. Because slapd_daemon_destroy can be called without slapd_deamon_init being called (e.g. if testing configuration, or giving -VV as the documentation suggests does something, though I'm not sure what), an attempt can be made to close sockets not opened. I suggest the following fix: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -79,7 +79,7 @@ #define SLAPD_LISTEN_BACKLOG 1024 #endif /* ! SLAPD_LISTEN_BACKLOG */ -static ber_socket_t wake_sds[2]; +static ber_socket_t wake_sds[2] = {INVALID_SOCKET, INVALID_SOCKET}; static int emfile; static volatile int waking; @@ -1641,8 +1643,10 @@ slapd_daemon_destroy( void ) { connections_destroy(); - tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); - tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); + if ( wake_sds[1] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); + if ( wake_sds[0] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); sockdestroy(); #ifdef HAVE_SLP I couldn't find this mentioned in your tracker already. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the second. It relates to back-sql, which I realise is unsupported on this platform, but seems to work very nicely once this and another bugfix or two (my other posts) are made. Mind you, I have only done a small amount of testing, and don't really understand what I am doing, as I am a complete newbie to LDAP. After sending these patches I intend to embark on a reading of your Administrator's Guide to learn. From the source code, though, I don't see why the problem would only apply to this platform anyway. It is this: When an SQL handle is opened, it is registered to be freed. When it is freed, however, it is not deregistered, so can easily be freed twice, particularly as to load the schemas the database connection is opened and closed. I suggest this patch to fix it (the patch looks larger than it really is as some code needed to be moved to ensure correct definition order): diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c openldap/servers/slapd/back-sql/sql-wrap.c --- openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c 2008-02-12 10:26:48.000000000 +1100 +++ openldap/servers/slapd/back-sql/sql-wrap.c 2008-06-28 22:29:25.000000000 +1000 @@ -462,28 +462,31 @@ return LDAP_SUCCESS; } +static void *backsql_db_conn_dummy; + +static void +backsql_db_conn_keyfree( + void *key, + void *data ) +{ + backsql_close_db_handle( (SQLHDBC)data ); +} + int backsql_free_db_conn( Operation *op, SQLHDBC dbh ) { Debug( LDAP_DEBUG_TRACE, "==>backsql_free_db_conn()\n", 0, 0, 0 ); (void)backsql_close_db_handle( dbh ); + ldap_pvt_thread_pool_setkey( op->o_threadctx, + &backsql_db_conn_dummy, (void *)SQL_NULL_HDBC, + backsql_db_conn_keyfree, NULL, NULL ); Debug( LDAP_DEBUG_TRACE, "<==backsql_free_db_conn()\n", 0, 0, 0 ); return LDAP_SUCCESS; } -static void *backsql_db_conn_dummy; - -static void -backsql_db_conn_keyfree( - void *key, - void *data ) -{ - backsql_close_db_handle( (SQLHDBC)data ); -} - int backsql_get_db_conn( Operation *op, SQLHDBC *dbhp ) { I could not find this issue already in your tracker. ------------------------------------------------------------------------

2 1

Re: (ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
by bgmilne＠staff.telkomsa.net 08 Jul '08

08 Jul '08

On Tuesday 08 July 2008 11:55:19 Howard Chu wrote: > bgmilne(a)staff.telkomsa.net wrote: > > Full_Name: Buchan Milne > > Version: 2.3.41 > > OS: Linux 2.6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (196.207.32.38) > > > > I have not run this same test case on 2.4.x yet, but I remember having > > problems trying to change passwords on 2.4.10 with a very similar > > configuration, so I think it exists in 2.4.10 as well. > > Please try this patch... Seems to fix it: [root@tiger ~]# ldappasswd -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Insufficient access (50) Additional info: Operations are restricted to bind/unbind/abandon/StartTLS/modify password [root@tiger ~]# urpmi openldap-servers To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "bgmilne") lib64ldap2.4_2 2.4.10 1.1mdv2008.1 x86_64 openldap 2.4.10 1.1mdv2008.1 x86_64 openldap-servers 2.4.10 1.1mdv2008.1 x86_64 9.5KB of additional disk space will be used. 1.5MB of packages will be retrieved. Proceed with the installation of the 3 packages? (Y/n) y installing lib64ldap2.4_2-2.4.10-1.1mdv2008.1.x86_64.rpm openldap-2.4.10-1.1mdv2008.1.x86_64.rpm openldap-servers-2.4.10-1.1mdv2008.1.x86_64.rpm from //home/bgmilne/rpm/mdk/RPMS.mdv2008.1/x86_64 Preparing... ############################################# 1/3: lib64ldap2.4_2 ############################################# 2/3: openldap ############################################# 3/3: openldap-servers ############################################# Stopping slapd: [ OK ] Starting slapd (ldap + ldaps): [ OK ] [root@tiger ~]# ldappasswd -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: [root@tiger ~]# Thanks, Buchan

1 0

Re: (ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
by hyc＠symas.com 08 Jul '08

08 Jul '08

This is a multi-part message in MIME format. --------------020700010705000602080304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.207.32.38) > I have not run this same test case on 2.4.x yet, but I remember having problems > trying to change passwords on 2.4.10 with a very similar configuration, so I > think it exists in 2.4.10 as well. Please try this patch... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------020700010705000602080304 Content-Type: text/plain; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dif.txt" Index: ppolicy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v retrieving revision 1.115 diff -u -r1.115 ppolicy.c --- ppolicy.c 12 Jun 2008 19:12:35 -0000 1.115 +++ ppolicy.c 8 Jul 2008 09:55:17 -0000 @@ -1401,7 +1401,7 @@ Attribute *pa, *ha, at; const char *txt; pw_hist *tl = NULL, *p; - int zapReset, send_ctrl = 0; + int zapReset, send_ctrl = 0, pwexop = 0; Entry *e; struct berval newpw = BER_BVNULL, oldpw = BER_BVNULL, *bv, cr[2]; @@ -1526,6 +1526,7 @@ req_pwdexop_s *qpw = sc->sc_private; newpw = qpw->rs_new; oldpw = qpw->rs_old; + pwexop = 1; break; } } @@ -1581,7 +1582,7 @@ } } - } else if ( !is_at_operational( ml->sml_desc->ad_type ) ) { + } else if ( !pwexop && !is_at_operational( ml->sml_desc->ad_type ) ) { mod_pw_only = 0; /* modifying something other than password */ } --------------020700010705000602080304--

1 0

Re: (ITS#5599) slapd dies on erroneous MOD input
by hasler＠ayni.com 07 Jul '08

07 Jul '08

Further to my report, i found the following in the syslog of when slapd had failed: Jul 7 07:05:31 myhost kernel: slapd[23962]: segfault at 0 ip 004cb118 sp b2b7c55c error 4 in libc-2.8.so[456000+163000] -- ---------------------------------------- Ayni AG Sternenstrasse 24 P.O.Box 1521 CH-8027 Zurich Switzerland, Europe +41 44 280 22 44, Fax +41 44 280 22 49 E-mail: nospam(a)ayni.com Web: http://www.ayni.com

1 0

(ITS#5601) set-acl failure under back-ldap+rwm
by mbackes＠symas.com 07 Jul '08

07 Jul '08

Full_Name: Matthew Backes Version: 2.3, 2.4 OS: all URL: Submission from: (NULL) (76.88.99.93) Set-acl who-clauses fail to match when accessing data through back-ldap and slapo-rwm. Given a local server with only the object: dn: cn=data,dc=local objectClass: organizationalPerson cn: data sn: sn data description: user where sn is an example attribute that we will protect: database bdb suffix "cn=data,dc=local" directory ./local checkpoint 1024 1 cachesize 10 index objectClass,dc,entryCSN,entryUUID eq index cn,sn,ou,title,description eq,sub access to dn.subtree="cn=data,dc=local" attrs=sn by set="user/title & this/description" write by * none access to dn.subtree="cn=data,dc=local" by * read So that any bound object with a title attribute matching the description attribute of the target should be able to see sn. Remote data: dn: dc=remote objectClass: organization objectClass: dcObject o: remote dc: remote dn: cn=user,dc=remote objectClass: organizationalPerson cn: user sn: user title: user userPassword: secret If we have the local slapd's back-ldap configured as: database ldap suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret then everything works correctly. But if we remap the DN using slapo-rwm instead: database ldap suffix "dc=remote,dc=local" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" Then the acl step fails: => access_allowed: read access to "cn=data,dc=local" "sn" requested => dn: [1] cn=data,dc=local => acl_get: [1] matched => acl_get: [1] attr sn access_allowed: no res from state (sn) => acl_mask: access to entry "cn=data,dc=local", attr "sn" requested => acl_mask: to value by "cn=user,dc=remote", (=0) <= check a_set_pat: user/title & this/description <= check a_dn_pat: * <= acl_mask: [2] applying none(=0) (stop) <= acl_mask: [2] mask: none(=0) => access_allowed: read access denied by none(=0) send_search_entry: conn 1 access to attribute sn, value #0 not allowed And the remote server was never queried for the title attribute.

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2008