openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by hyc＠symas.com 17 Sep '14

17 Sep '14

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > Found this at a customer site. They loaded an LDIF file that had the child of > an entry, but not the entry itself. slapadd then created a glue entry to > account for this, however there some significant problems with this process > > a) The glue entry is not syntactically correct. There is no RDN value. > > b) It is impossible to use a filter with ldapsearch to find the entry. It > appears the objectClass index is utterly broken. Works as designed. Closing this ITS. > > Example entry, and the child that created it: > > dn: uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy > entryUUID: a326899a-ad0e-1033-8edf-d9cf7a32cf04 > creatorsName: cn=config > createTimestamp: 20140731145640Z > entryCSN: 20140731145640.037371Z#000000#002#000000 > modifiersName: cn=config%momodifyTimestamp: 20140731145640Z > objectClass: top > objectClass: glue > structuralObjectClass: glue > > dn: zimbraDataSourceName=Adinet,uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy > objectClass: zimbraDataSource > objectClass: zimbraImapDataSource > .... > > As we can see, the glue entry has no RDN attribute at all. It is also > impossible to find this entry via ldapsearch; > > ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url > -b "ou=people,dc=xxxx,dc=com,dc=uy" uid=abcd > [zimbra@ldap01 ~]$ > > [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w > $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" > "(objectClass=glue)" 1.1 > [zimbra@ldap01 ~]$ > > > > -- -- 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#7939) Unable to filter on "(objectClass=glue)"
by hyc＠symas.com 17 Sep '14

17 Sep '14

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > When trying to find a set of broken entries, I found that it is impossible to > filter on objectClass=glue: > > [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w > $zimbra_ldap_password -H $ldap_url -b > "ou=people,dc=xxx,dc=xxx,dc=xxx%2%2"(objectClass=glue)" 1.1 > [zimbra@ldap01 ~]$ echo $? > 0 > > I am immediately returned to the prompt, and the error result is success (0). > Instead, I expect all the broken glue'd objects returned instead. Use the manageDSAit control. This works as designed, no bug, closing this 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

(ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by quanah＠openldap.org 17 Sep '14

17 Sep '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 3.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) Found this at a customer site. They loaded an LDIF file that had the child of an entry, but not the entry itself. slapadd then created a glue entry to account for this, however there some significant problems with this process a) The glue entry is not syntactically correct. There is no RDN value. b) It is impossible to use a filter with ldapsearch to find the entry. It appears the objectClass index is utterly broken. Example entry, and the child that created it: dn: uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy entryUUID: a326899a-ad0e-1033-8edf-d9cf7a32cf04 creatorsName: cn=config createTimestamp: 20140731145640Z entryCSN: 20140731145640.037371Z#000000#002#000000 modifiersName: cn=config%momodifyTimestamp: 20140731145640Z objectClass: top objectClass: glue structuralObjectClass: glue dn: zimbraDataSourceName=Adinet,uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy objectClass: zimbraDataSource objectClass: zimbraImapDataSource .... As we can see, the glue entry has no RDN attribute at all. It is also impossible to find this entry via ldapsearch; ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" uid=abcd [zimbra@ldap01 ~]$ [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" "(objectClass=glue)" 1.1 [zimbra@ldap01 ~]$

1 0

Re: (ITS#7939) Unable to filter on "(objectClass=glue)"
by quanah＠zimbra.com 17 Sep '14

17 Sep '14

--On Wednesday, September 17, 2014 1:11 AM +0000 quanah(a)openldap.org wrote: > When trying to find a set of broken entries, I found that it is > impossible to filter on objectClass=glue: Never mind, the entries aren't even valid ldap entries. Closing this ITS. -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7939) Unable to filter on "(objectClass=glue)"
by quanah＠openldap.org 17 Sep '14

17 Sep '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 3.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) When trying to find a set of broken entries, I found that it is impossible to filter on objectClass=glue: [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxx,dc=xxx,dc=xxx%2%2"(objectClass=glue)" 1.1 [zimbra@ldap01 ~]$ echo $? 0 I am immediately returned to the prompt, and the error result is success (0). Instead, I expect all the broken glue'd objects returned instead.

1 0

Re: (ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by ondra＠mistotebe.net 15 Sep '14

15 Sep '14

On Fri, Jan 10, 2014 at 04:40:39AM +0000, fumiyas(a)osstech.co.jp wrote: > If slapd.conf has the following config, slapd segfault at startup. > > overlay constraint > constraint_attribute memberUid size 0 > # or > constraint_attribute memberUid count 0 Hi, I've uploaded a fix to this issue and #7781 to ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20140915-ITS-7780-7781.tgz could you confirm it fixes the issues for you? The above patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the above patches were developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondřej Kuzník, hereby place the above 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. Cheers, Ondrej

1 0

Re: (ITS#7938) OpenLDAP using SASL Authentifikation
by quanah＠zimbra.com 15 Sep '14

15 Sep '14

--On Monday, September 15, 2014 12:19 PM +0000 sharbich(a)t-online.de wrote: > Full_Name: Stefan Harbich > Version: 2.4.31-1+nmu2 / amd64 > OS: Debian Wheezy 7.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.128.80.149) The ITS system is for reporting bugs, not asking usage questions. Please use the openldap-technical(a)openldap.org discussion list for questions. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7938) OpenLDAP using SASL Authentifikation
by sharbich＠t-online.de 15 Sep '14

15 Sep '14

Full_Name: Stefan Harbich Version: 2.4.31-1+nmu2 / amd64 OS: Debian Wheezy 7.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.128.80.149) Hello everyone, at the imput: abc@xyz01:~$ ldapsearch -b "dcSubMailAddress=sharbich(a)t-online.de,uid=test,ou=users,dc=xyz,dc=de", i get the following result appears: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: unable to canonify user and get auxprops. I run the command as root: root@xyz01:# ldapsearch -b dcSubMailAddress=xyz(a)t-online.de,uid=test,ou=users,dc=xyz,dc=de lists all values of the user. Can the problem be due to the authorization? Many Thanks, by Stefan Harbich

1 0

Re: (ITS#7937) back-sock does not flush data to socket
by hyc＠symas.com 11 Sep '14

11 Sep '14

pdg(a)uow.edu.au wrote: > Full_Name: Peter Gray > Version: 2.4.39 > OS: solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.130.37.84) > > > The code in back-sock seems to have an error. > > It opens a socket, converts the socket fd to a FILE *, and uses fprintf to send > data to the socket. For example, from search.c: Thanks for the report, fixed in git master. > > > fprintf( fp, "SEARCH\n" ); > fprintf( fp, "msgid: %ld\n", (long) op->o_msgid ); > sock_print_conn( fp, op->o_conn, si ); > sock_print_suffixes( fp, op->o_bd ); > fprintf( fp, "base: %s\n", op->o_req_dn.bv_val ); > fprintf( fp, "scope: %d\n", op->oq_search.rs_scope ); > fprintf( fp, "deref: %d\n", op->oq_search.rs_deref ); > fprintf( fp, "sizelimit: %d\n", op->oq_search.rs_slimit ); > fprintf( fp, "timelimit: %d\n", op->oq_search.rs_tlimit ); > fprintf( fp, "filter: %s\n", op->_s_search.rs_filterstr.bv_val ); > fprintf( fp, "attrsonly: %d\n", op->oq_search.rs_attrsonly ? 1 : 0 ); > fprintf( fp, "attrs:%s", op->oq_search.rs_attrs == NULL ? " all" : "" > ); > for ( an = op->oq_search.rs_attrs; an && an->an_name.bv_val; an++ ) { > fprintf( fp, " %s", an->an_name.bv_val ); > } > fprintf( fp, "\n\n" ); /* end of attr line plus blank line */ > > /* read in the results and send them along */ > rs->sr_attrs = op->oq_search.rs_attrs; > sock_read_and_send_results( op, rs, fp ); > > However, it fails to flush the stream, so in sock_read_and_send_results when it > issues a read from the socket, the data written has not been seen by the socket > endpoint. > > This results in deadlock when slapd is waiting on the read, and the daemon on > the other end of the socket is waiting on the ldap query. > > My fix is to call fflush as the first operation on sock_read_and_send_results > and this worked fine. > > Here is the diff. > *** .snapshot/nightly.0/result.c Sun Jan 26 00:36:15 2014 > --- result.c Thu Sep 11 11:25:07 2014 > *************** > *** 48,53 **** > --- 48,54 ---- > char line[BUFSIZ]; > char ebuf[128]; > > + (void) fflush(fp); > /* read in the result and send it along */ > buf = (char *) ch_malloc( BUFSIZ ); > buf[0] = '\0'; > > > > -- -- 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#7937) back-sock does not flush data to socket
by pdg＠uow.edu.au 11 Sep '14

11 Sep '14

Full_Name: Peter Gray Version: 2.4.39 OS: solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.130.37.84) The code in back-sock seems to have an error. It opens a socket, converts the socket fd to a FILE *, and uses fprintf to send data to the socket. For example, from search.c: fprintf( fp, "SEARCH\n" ); fprintf( fp, "msgid: %ld\n", (long) op->o_msgid ); sock_print_conn( fp, op->o_conn, si ); sock_print_suffixes( fp, op->o_bd ); fprintf( fp, "base: %s\n", op->o_req_dn.bv_val ); fprintf( fp, "scope: %d\n", op->oq_search.rs_scope ); fprintf( fp, "deref: %d\n", op->oq_search.rs_deref ); fprintf( fp, "sizelimit: %d\n", op->oq_search.rs_slimit ); fprintf( fp, "timelimit: %d\n", op->oq_search.rs_tlimit ); fprintf( fp, "filter: %s\n", op->_s_search.rs_filterstr.bv_val ); fprintf( fp, "attrsonly: %d\n", op->oq_search.rs_attrsonly ? 1 : 0 ); fprintf( fp, "attrs:%s", op->oq_search.rs_attrs == NULL ? " all" : "" ); for ( an = op->oq_search.rs_attrs; an && an->an_name.bv_val; an++ ) { fprintf( fp, " %s", an->an_name.bv_val ); } fprintf( fp, "\n\n" ); /* end of attr line plus blank line */ /* read in the results and send them along */ rs->sr_attrs = op->oq_search.rs_attrs; sock_read_and_send_results( op, rs, fp ); However, it fails to flush the stream, so in sock_read_and_send_results when it issues a read from the socket, the data written has not been seen by the socket endpoint. This results in deadlock when slapd is waiting on the read, and the daemon on the other end of the socket is waiting on the ldap query. My fix is to call fflush as the first operation on sock_read_and_send_results and this worked fine. Here is the diff. *** .snapshot/nightly.0/result.c Sun Jan 26 00:36:15 2014 --- result.c Thu Sep 11 11:25:07 2014 *************** *** 48,53 **** --- 48,54 ---- char line[BUFSIZ]; char ebuf[128]; + (void) fflush(fp); /* read in the result and send it along */ buf = (char *) ch_malloc( BUFSIZ ); buf[0] = '\0';

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