- openldap-bugs - openldap.org

Re: (ITS#5000) slapd with invalid url causes crashes
by hyc＠symas.com 07 Jun '07

07 Jun '07

This is most likely the same as ITS#4957 which has already been fixed in the new release candidate. This ITS will be closed. jl+openldap(a)lists.wasmer.ca wrote: > Full_Name: Jean-Luc Wasmer > Version: 2.3.32 > OS: NetBSD 4.0 Beta2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (70.50.240.203) > > > > When slapd is started with an invalid url, it looks like it's trying to destroy > an uninitialized mutex: > > Program received signal SIGABRT, Aborted. > 0xbb87dfff in kill () from /usr/lib/libc.so.12 > (gdb) backtrace > #0 0xbb87dfff in kill () from /usr/lib/libc.so.12 > #1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 > #2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 > #3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from > /usr/pkg/lib/libldap_r-2.3.so.0 > #4 0x0805a756 in ?? () > #5 0x0819e4fc in __ps_strings () > #6 0x00000002 in ?? () > #7 0xbfbfe8e8 in ?? () > #8 0x0805a713 in ?? () > #9 0x00000286 in ?? () > #10 0x00000001 in ?? () > #11 0xbfbfe958 in ?? () > #12 0x0804e2c1 in ?? () > #13 0xbfa00000 in ?? () > #14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 > #15 0x00000002 in ?? () > #16 0x00000000 in ?? () > > Invalid argument that triggered the bug: > -h 'ldap://127.0.0.1 ldaps://<external ip>' > with no interfaces on the system configured with <external ip> > > > . > -- -- 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#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 07 Jun '07

07 Jun '07

Hi Pierangelo; Unfortunately I reproduced the problem with the HEAD dated June 5. If I do not add a rootdn to the monitor database, slapd cannot start. At the end of the log I find : monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=c=fr)": unable to find entry ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (-1) slapd shutdown: initiated ====> bdb_cache_release_all bdb_db_close: alock_close failed slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. Is the rootdn mandatory for monitor ? Best Regards Ali

1 0

(ITS#5000) slapd with invalid url causes crashes
by jl+openldap＠lists.wasmer.ca 06 Jun '07

06 Jun '07

Full_Name: Jean-Luc Wasmer Version: 2.3.32 OS: NetBSD 4.0 Beta2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.50.240.203) When slapd is started with an invalid url, it looks like it's trying to destroy an uninitialized mutex: Program received signal SIGABRT, Aborted. 0xbb87dfff in kill () from /usr/lib/libc.so.12 (gdb) backtrace #0 0xbb87dfff in kill () from /usr/lib/libc.so.12 #1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 #2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 #3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from /usr/pkg/lib/libldap_r-2.3.so.0 #4 0x0805a756 in ?? () #5 0x0819e4fc in __ps_strings () #6 0x00000002 in ?? () #7 0xbfbfe8e8 in ?? () #8 0x0805a713 in ?? () #9 0x00000286 in ?? () #10 0x00000001 in ?? () #11 0xbfbfe958 in ?? () #12 0x0804e2c1 in ?? () #13 0xbfa00000 in ?? () #14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 #15 0x00000002 in ?? () #16 0x00000000 in ?? () Invalid argument that triggered the bug: -h 'ldap://127.0.0.1 ldaps://<external ip>' with no interfaces on the system configured with <external ip>

1 0

(ITS#4999) Dead Link
by ghenry＠OpenLDAP.org 06 Jun '07

06 Jun '07

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dead link: http://www.openldap.org/project/software/repo.html Thanks, Gavin.

1 0

Re: (ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by msl＠calivia.com 04 Jun '07

04 Jun '07

Howard Chu wrote: > msl(a)calivia.com wrote: >> Full_Name: Michael Steinmann >> Version: 2.3.35 / HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.254.173.218) >> >> >> This is while testing a custom pwdCheckModule. >> In function check_password_quality(), char *txt is free()'d, slapd >> crashes with >> "invalid pointer". > > The code works as designed (and as documented). Re-read the > slapo-ppolicy(5) manpage. This ITS will be closed. Got it, thanks. Sorry for the noise. -- mike

1 0

Re: (ITS#4629) slapd failure on HP-UX 11.23/IA 64-bit
by h.b.furuseth＠usit.uio.no 04 Jun '07

04 Jun '07

I've been looking rather belatedly at this patch... it's simple, but the type name ACCEPT_TYPE_ARG3 is a bit ugly to use in .c source files instead of socklen_t. What's the "nice" way to do this? It's an internal type dependent on compiler switches (-D_XOPEN_SOURCE_EXTENDED on HP-UX), so I don't think it is wise to expose it in lber_types.h. It depends on <sys/socket.h> anyway. If not... just use ACCEPT_TYPE_ARG3 or maybe AC_SOCKLEN_T directly in .c files? #define AC_SOCKLEN_T in portable.h and typedef ac_socklen_t as it in sys/socket.h? Cheat and #define ber_socklen_t in portable.h? Also the patch is incomplete, we need to use this type (or some configured type) in getpeername(), getsockopt() and recvfrom() too. I _hope_ they all use the same type or at least a type with the same size on all these platforms... Googling around a bit, the mess with socklen_t and accept() prototypes seems amazing. I'm not sure I dare commit a patch which fails if it doesn't figure out the right type. At least not to RE23 - I'll commit a patch there which just guesses socklen_t or int if it can't figure out the right prototype. We can try one which fails in that case in HEAD and see if anyone complain. If we are going to be as paranoid as some other code out there, it'd be something like this (and even more if we want to try until succeeding in HEAD) - that's 12 compiles instead of the 5 in the submitted patch. Quite a lot... dnl socklen_t-like type in accept(), default socklen_t or int: dnl - The OS might define socklen_t without using it. POSIX moved from dnl int to size_t to socklen_t, hoping to stay at a 32-bit type, and dnl HP-UX has selectors for what to use. dnl - On Solaris 2.8 the prototype has void *len, but the default is OK. AC_MSG_CHECKING([for socklen_t-like type in accept()]) AC_CACHE_VAL(ol_cv_type_lber_socklen_t, [ set socklen_t int unsigned "unsigned long" long size_t test "$ac_cv_type_socklen_t" = yes || shift ol_cv_type_lber_socklen_t=$1 guessing="guessing " for lentype in "$@" ; do for addrtype in "struct sockaddr" void ; do AC_COMPILE_IFELSE([AC_LANG_PROGRAM([$ac_includes_default #ifdef HAVE_SYS_SOCKET_H #include <sys/socket.h> #endif extern int accept(int s, $addrtype *ap, $lentype *lp); ], [ $lentype len; accept(0, (struct sockaddr *) 0, &len); ])], [ol_cv_type_lber_socklen_t=$lentype guessing= ; break 2]) done ; done]) AC_MSG_RESULT([$guessing$ol_cv_type_lber_socklen_t]) AC_DEFINE_UNQUOTED(LBER_SOCKLEN_T, $ol_cv_type_lber_socklen_t, [define to socklen_t-like type in accept()]) -- Regards, Hallvard

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 04 Jun '07

04 Jun '07

ali.pouya(a)free.fr wrote: > Hi Pierangelo; > As you requested, you find below my simplified slapd.conf. > If I comment the line "access to dn.sub="cn=monitor" by * read", then slapd > cannot start. HEAD is working as expected (slapd starts, although it cannot register the database specific monitor info). If a rootdn is added to the monitor database, it starts just fine. What version are you testing? Since this is a > 2.3 specific feature, anything earlier than HEAD will not be considered. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by h.b.furuseth＠usit.uio.no 04 Jun '07

04 Jun '07

hyc(a)symas.com writes: >> This is while testing a custom pwdCheckModule. >> In function check_password_quality(), char *txt is free()'d, slapd >> crashes with "invalid pointer". > > The code works as designed (and as documented). Re-read the > slapo-ppolicy(5) manpage. This ITS will be closed. Actually I think it has a doc bug anyway. See ITS#4901: memory malloced in one Windows DLL must be freed by the same DLL. So the manpage needs to specify _which_ allocation function to use: either ber_memalloc() or slap_sl_malloc(). Because proto-slap.h #defines free to ch_free, which uses ber_memfree_x() or slap_sl_free(). -- Regards, Hallvard

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 04 Jun '07

04 Jun '07

Hi Pierangelo; As you requested, you find below my simplified slapd.conf. If I comment the line "access to dn.sub="cn=monitor" by * read", then slapd cannot start. Best regards Ali ==================================================== include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/ppolicy.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args access to attrs=userPassword by anonymous auth by * none access to dn.sub="cn=monitor" by * read access to * by * none database monitor database bdb serverID 1 suffix "c=fr" rootdn cn=admin,ou=internal,o=gouv,c=fr rootpw {SSHA}1QuNDW3pqQDP93tMcyXo6ClZBJ2VP5XG directory /produits/bdb/data checkpoint 1000000 10 index objectClass,entryCSN,entryUUID eq index uid,cn eq,sub,pres overlay syncprov syncprov-checkpoint 1000 10 syncprov-sessionlog 1000 syncprov-reloadhint TRUE overlay ppolicy ppolicy_hash_cleartext

1 0

Re: (ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by hyc＠symas.com 03 Jun '07

03 Jun '07

msl(a)calivia.com wrote: > Full_Name: Michael Steinmann > Version: 2.3.35 / HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.254.173.218) > > > This is while testing a custom pwdCheckModule. > In function check_password_quality(), char *txt is free()'d, slapd crashes with > "invalid pointer". The code works as designed (and as documented). Re-read the slapo-ppolicy(5) manpage. This ITS will be closed. -- -- 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#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 03 Jun '07

03 Jun '07

Hello... ando(a)sys-net.it wrote: > You pointed out a misalignment between documentation and code, which > was the result of a continuous evolution of both in an attempt to > make dynlist as general as possible while letting it keep > contradictory configurations under control. The checks currently > implemented resulted too strict, so I relaxed them. Maybe they are > now too relaxed (you just get a warning if you do something odd, but > then the oddest thing you could do would result at most in slowing > down the DSA you admin). Please check if the current code satisfies > your requirements so that the change can be released ASAP. I checked out CVS "HEAD" code, if that is, what cvs -z3 co -P openldap with CVSROOT=:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP does, configured and built it. I might have used a slightly different configuration than my current production environment, but after building I was able to run slapd without even a warning about the following configuration: overlay dynlist dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL owner So, the relaxation of the config checking seems to be successful. Thanks for your fast reaction to my issue report. bye Christian -- Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request>

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it 03 Jun '07

03 Jun '07

I think you need to realize that dynlist (and dynamic groups in general) represent an abuse of the LDAP data model. You pointed out a misalignment between documentation and code, which was the result of a continuous evolution of both in an attempt to make dynlist as general as possible while letting it keep contradictory configurations under control. The checks currently implemented resulted too strict, so I relaxed them. Maybe they are now too relaxed (you just get a warning if you do something odd, but then the oddest thing you could do would result at most in slowing down the DSA you admin). Please check if the current code satisfies your requirements so that the change can be released ASAP. Don't expect dynlist to do all you want it to do, and exactly as you want it, because it needs to satisfy other requirements as well. If you want to design specs for dynamic groups, or dynamic lists, maybe an ITS is not the right forum. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by msl＠calivia.com 03 Jun '07

03 Jun '07

Full_Name: Michael Steinmann Version: 2.3.35 / HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.254.173.218) This is while testing a custom pwdCheckModule. In function check_password_quality(), char *txt is free()'d, slapd crashes with "invalid pointer". Core was generated by `servers/slapd/slapd -f etc/openldap/slapd.conf -h ldap://localhost:10389/ -d 9'. Program terminated with signal 6, Aborted. #0 0xb7b3a0b6 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b3a0b6 in raise () from /lib/libc.so.6 #1 0xb7b3b841 in abort () from /lib/libc.so.6 #2 0xb7b7019b in __libc_message () from /lib/libc.so.6 #3 0xb7b75de2 in malloc_printerr () from /lib/libc.so.6 #4 0x08089bb8 in ch_free (ptr=0xb7c3aff4) at ch_malloc.c:139 #5 0x08119833 in check_password_quality (cred=0x2, pp=<value optimized out>, err=0xb752becc, e=0x8285998) at ppolicy.c:650 #6 0x0811ac59 in ppolicy_modify (op=0x8285028, rs=0xb752c1c4) at ppolicy.c:1751 #7 0x080c7134 in overlay_op_walk (op=0x8285028, rs=0xb752c1c4, which=op_modify, oi=0x822f488, on=0x822f578) at backover.c:498 #8 0x080c758d in over_op_func (op=0x8285028, rs=0xb752c1c4, which=op_modify) at backover.c:560 #9 0x080a117b in passwd_extop (op=0x8285028, rs=0xb752c1c4) at passwd.c:284 #10 0x0809f611 in fe_extended (op=0x8285028, rs=0xb752c1c4) at extended.c:215 #11 0x0809fb79 in do_extended (op=0x8285028, rs=0xb752c1c4) at extended.c:180 #12 0x08070589 in connection_operation (ctx=0xb752c238, arg_v=0x8285028) at connection.c:1133 #13 0x08143ae3 in ldap_int_thread_pool_wrapper (xpool=0x820eb40) at tpool.c:478 #14 0xb7c43f8a in start_thread () from /lib/libpthread.so.0 #15 0xb752c480 in ?? () #16 0xb752c480 in ?? () #17 0xb752c480 in ?? () #18 0xb752c480 in ?? () #19 0x00000000 in ?? () Patch below fixes the issue. Index: ppolicy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v retrieving revision 1.98 diff -r1.98 ppolicy.c 652d651 < free(txt);

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 03 Jun '07

03 Jun '07

Hello Kurt, Kurt Zeilenga wrote: > On Jun 2, 2007, at 2:47 PM, marg(a)rz.tu-clausthal.de wrote: [...] >> posixGroup and groupOfURLs are both "structural" objectclasses so >> an entry is either a "groupofURL" or a "posixGroup", never both. > > Yes, but an entry can belong to both. That is, an entry's structural > class could inherit from both of these classes. I didn't know that multiple inheritance existed in an LDAP schema. Or did you mean that there is an inheritance chain like: "top - person - organisationalPerson - inetOrgPerson"? In the latter case - if dynlist honored inheritance - the rules should be made clear: 1st example: dynlist-attrset person personURL dynlist-attrset inetOrgPerson inetOrgPersonURL No problem: An inetOrgPerson-Object is encountered and if both *URL-Attributes were defined, both would be expanded. 2nd example: dynlist-attrset person someURL dynlist-attrset inetOrgPerson someURL In this case there would have to be rule for matching: Either first-match or most exact match. >> And in this case the memberURL can have different meanings >> according to the Objectclass it is used in. > > That's called bad schema design. If an attribute has is specified to > have different meaning when used with X then when used with Y, it's > not only unclear what meaning the attribute as when used with both X > and Y, but also used without either X or Y. Ok, I was beeing unclear: memberURL of course has no different meaning in two different group type OCs - it is the URL that lists the members of that group. Only difference is that OC 'A' might not allow attribute 'S' returned by the LDAP URL used for expansion in OC 'B', while OC 'B' might not allow attribute 'T' returned by the LDAP URL used for expansion in OC 'A'. Still both LDAP URLs are values of the Attribute "memberURL". And no schema constraint I know of can control what an LDAP URL specifies. I could add multiple Attribute-Descriptions (SUP labeledURI) like: uidexpansionURL - containing only LDAP URLS like ldap:///<base>?uid?<scope>?<filter> mailexpansionURL - containing only LDAP URLS like ldap:///<base>?mail?<scope>?<filter> but now I've got two different objectclasses that should list a set of mail adresses - what should I do? Should I really define two attributes OCAmailexpansionURL and OCBmailexpansionURL just to satisfy current(?) dynlist configuration rules? I think that would be bad schema design: Different attributes for values meaning the same. > Note that attributes may be added to an entry which are not allowed > by any of the classes the entry belongs to... (see DIT content > rules). The addition of the "extensibleObject" OC is the closest thing I've seen to what I understand from that sentence. I just don't understand what this has to do with Pierangelo believing that expansion of the same URL attribute in different object classes should be forbidden. bye Christian -- Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request>

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by kurt＠OpenLDAP.org 03 Jun '07

03 Jun '07

On Jun 2, 2007, at 2:47 PM, marg(a)rz.tu-clausthal.de wrote: > Hello... > > ando(a)sys-net.it wrote: >> marg(a)rz.tu-clausthal.de wrote: >> >>> I found a behaviour issue with the dynlist overlay configuration: >>> >>> I tried the following configuration: >>> >>> overlay dynlist >>> dynlist-attrset posixGroup memberURL >>> dynlist-attrset groupOfURLs memberURL owner >> >> The reason of that check is that the same attribute "memberURL" could >> otherwise be used by both group classes to expand. > > [...] > >> However, I believe something like >> >> dynlist-attrset posixGroup memberURL >> dynlist-attrset groupOfURLs memberURL >> >> should still be forbiden, otherwise the same "memberURL" would expand >> twice. This, strictly speaking, is not an issue, as duplicates would >> simply be discarded, but it would cause unnecessary overhead. Right >> now, I have decided to turn this check into a config-time warning. > > Hmm - I object. > > posixGroup and groupOfURLs are both "structural" objectclasses so an > entry is either a "groupofURL" or a "posixGroup", never both. Yes, but an entry can belong to both. That is, an entry's structural class could inherit from both of these classes. > And in > this case the memberURL can have different meanings according to the > Objectclass it is used in. That's called bad schema design. If an attribute has is specified to have different meaning when used with X then when used with Y, it's not only unclear what meaning the attribute as when used with both X and Y, but also used without either X or Y. Note that attributes may be added to an entry which are not allowed by any of the classes the entry belongs to... (see DIT content rules). > Otherwise I'd have to create an Attribute for every expansion I > want to > use - that can't be right! > > You are right for expansions in auxillary OCs, of course! They > shouldn't > be using the same attribute... > >> Please test and report. > > Will do, sometime soon. > > bye > Christian > -- > Christian Marg mail: mailto:marg@rz.tu-clausthal.de > Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de > D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 > Germany ICQ : <on request> > >

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 03 Jun '07

03 Jun '07

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig98A1F9874D1718E82ABEA8E9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello. Pierangelo Masarati wrote: > Christian Marg wrote: >=20 >> Hmm - I object. >> >> posixGroup and groupOfURLs are both "structural" objectclasses so an >> entry is either a "groupofURL" or a "posixGroup", never both. >=20 > OK, my example was stupid. But you got the idea below. >=20 >> You are right for expansions in auxillary OCs, of course! They shouldn= 't >> be using the same attribute... Couldn't the config file check test if the OC is structural/auxilliary? Do you expand for OC InetOrgPerson if an expansion was configured for OC Person? I can configure an expansion for the abstract objectclass "TOP" without any error message (that doesn't really make sense, I know, because they don't exist in the directory) - if you'd respect inheritance that would be a fun thing to do - every Objectclass is (in-)directly inherited from "TOP" ;) bye Christian --=20 Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request> --------------enig98A1F9874D1718E82ABEA8E9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYtNyXwu7mUb3ymMRAoO/AJ9vdGCDBj3yGCUYjkOEppngJRWdzACffxB0 WuO/HvOk3KkVUzg5k6VA20g= =Y3xR -----END PGP SIGNATURE----- --------------enig98A1F9874D1718E82ABEA8E9--

1 0

Re: (ITS#4994) Clarify -y option in man pages
by rra＠stanford.edu 02 Jun '07

02 Jun '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > rra(a)stanford.edu wrote: >> A Debian user was confused by the -y option and its inclusion of >> whitespace in the password. The current man page text does explain >> this, but it doesn't make a point of it, and I think a bit more >> explanation would be useful. Here's a patch for the ldapcompare.1 man >> page; if you think this is a good idea, similar changes could be made >> to all the other command-line utilities that take the -y option. > I have committed a different clarification that provides a hint to a > portable manner to generate appropriate password files. Please check > and improve; afterwards I'll apply it to other command line tools man > pages. Perfect, and a substantial improvement over my patch. Thank you! -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4997) lmpasswd support using gcrypt
by rra＠stanford.edu 02 Jun '07

02 Jun '07

Kurt Zeilenga <kurt(a)OpenLDAP.org> writes: > Without involvement from the authors of this patch, it's better to > simply rewrite the feature from scratch. No problem. The patch is conceptually trivial. I'll plan on reimplementing it from scratch unless I can contact the original author (or possibly anyway if it's faster). -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4971)
by ando＠sys-net.it 02 Jun '07

02 Jun '07

jemeterisan(a)mail.ru wrote: > O.k, thanks. But, I would like to know, what does the termin "HEAD > code" mean? the HEAD branch out of the CVS. > And where can I get it? <http://www.openldap.org/software/repo.html#AnonCVS> >> Any blob-like format would be fine (although I haven't tested it >> with PostgreSQL yet). > > So, do You mean BLOB-like format as oid (in PostgreSQL), or just > something like varbit type? I'm not that familiar with variable size binary data in PostgreSQL, but I guess something like "bytea" should work. With MySQL, "LONGBLOB" worked. > I tried to put BLOBs in PostgreSQL by > ldapadd - it's possible. Usually, you need to encode those objects in a way ldapadd can munch. For example, base64 encode them, like binaryAttr:: thisisabase64encodedvalue= or ask it to swallow the file as is, using binaryAttr:< file:///path/to/binary.dat > But I had some problems when I tried to read > from oid. I just had got the value of oid, but not stored data. Not sure I understand what you mean. But here we're getting off-topic with this ITS; please continue discussion, if needed, on the openldap-software mailing list. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4971)
by h.b.furuseth＠usit.uio.no 02 Jun '07

02 Jun '07

jemeterisan(a)mail.ru writes: > what does the termin "HEAD code" mean? > And where can I get it? Sorry for my educationless... The source code is stored in a CVS repository, as described here: http://www.openldap.org/software/repo.html The development branch is named HEAD. As the above URL says, you can check it out with % setenv CVSROOT :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP % cvs login Password: (enter OpenLDAP) % cvs -z3 checkout -P ldap % cvs logout -- Regards, Hallvard

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it 02 Jun '07

02 Jun '07

Christian Marg wrote: > Hmm - I object. > > posixGroup and groupOfURLs are both "structural" objectclasses so an > entry is either a "groupofURL" or a "posixGroup", never both. OK, my example was stupid. But you got the idea below. > And in > this case the memberURL can have different meanings according to the > Objectclass it is used in. > > Otherwise I'd have to create an Attribute for every expansion I want to > use - that can't be right! > > You are right for expansions in auxillary OCs, of course! They shouldn't > be using the same attribute... > >> Please test and report. > > Will do, sometime soon. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 02 Jun '07

02 Jun '07

Hello... ando(a)sys-net.it wrote: > marg(a)rz.tu-clausthal.de wrote: > >> I found a behaviour issue with the dynlist overlay configuration: >> >> I tried the following configuration: >> >> overlay dynlist >> dynlist-attrset posixGroup memberURL >> dynlist-attrset groupOfURLs memberURL owner > > The reason of that check is that the same attribute "memberURL" could > otherwise be used by both group classes to expand. [...] > However, I believe something like > > dynlist-attrset posixGroup memberURL > dynlist-attrset groupOfURLs memberURL > > should still be forbiden, otherwise the same "memberURL" would expand > twice. This, strictly speaking, is not an issue, as duplicates would > simply be discarded, but it would cause unnecessary overhead. Right > now, I have decided to turn this check into a config-time warning. Hmm - I object. posixGroup and groupOfURLs are both "structural" objectclasses so an entry is either a "groupofURL" or a "posixGroup", never both. And in this case the memberURL can have different meanings according to the Objectclass it is used in. Otherwise I'd have to create an Attribute for every expansion I want to use - that can't be right! You are right for expansions in auxillary OCs, of course! They shouldn't be using the same attribute... > Please test and report. Will do, sometime soon. bye Christian -- Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request>

1 0

(ITS#4971)
by jemeterisan＠mail.ru 02 Jun '07

02 Jun '07

-----Original Message----- From: Pierangelo Masarati <ando(a)sys-net.it> To: jemeterisan(a)mail.ru Date: Fri, 18 May 2007 19:10:03 +0200 Subject: Re: (ITS#4971) patch for OpenLDAP 2-3-32 > I assume you refer to a patch that was submitted along with ITS#4868; > that patch is absolutely incorrect and in fact it has been rejected. A > consistent fix has been applied to hEAD code. It has never been > backported to OpenLDAP 2.3 because nobody fed back about it. If you > wish to test HEAD code and report success, I'll be happy to backport it > to OpenLDAP 2.3 so that it gets released with the next release. > O.k, thanks. But, I would like to know, what does the termin "HEAD code" mean? And where can I get it? Sorry for my educationless... > Any blob-like format would be fine (although I haven't tested it with > PostgreSQL yet). So, do You mean BLOB-like format as oid (in PostgreSQL), or just something like varbit type? I tried to put BLOBs in PostgreSQL by ldapadd - it's possible. But I had some problems when I tried to read from oid. I just had got the value of oid, but not stored data. With best wishes, Dmitry...

1 0

Re: (ITS#4997) lmpasswd support using gcrypt
by kurt＠OpenLDAP.org 02 Jun '07

02 Jun '07

On Jun 2, 2007, at 6:31 AM, rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.4 (HEAD) > OS: Debian > URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341 > Submission from: (NULL) (171.66.157.14) > > > Now that 2.4 has native GnuTLS support, the patch that's been > sitting around in > Debian bug #245341 becomes potentially interesting (see the > associated URL). > This is a request to support LAN Manager password hashes when > OpenLDAP is built > with GnuTLS instead of OpenSSL, thus requiring using libgcrypt to > do the DES > work instead of OpenSSL's DES library. > > The patch in that bug almost certainly isn't okay in its current form, Note that 3rd party contributions are generally not acceptable (for IPR reasons). That is, we generally require the author(s) of the patch to contribute the patch. If you think this patch is useful, you might suggest to its authors that they contribute it to the Project. In doing so, it's good to provide a link to our contributing guidelines, http://www.openldap.org/devel/ contributing.html. > but I > wanted to get the ITS filed for this feature request so that > there's a record in > the database and just in case someone else feels inspired to bring > the patch up > to date and clean it up. (Unlikely, I know.) Otherwise, I will > probably clean > this patch up for further submission at some point near the 2.4 > release (on > which side of it, I'm not sure). Without involvement from the authors of this patch, it's better to simply rewrite the feature from scratch. -- Kurt

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 02 Jun '07

02 Jun '07

richton(a)nbcs.rutgers.edu wrote: Committed. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs