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/
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';
requate(a)univention.de wrote:
> Full_Name: Arvid Requate
> Version: 2.4.35
> OS: Debian / UCS
> URL: http://apt.univention.de/download/temp/openldap/
> Submission from: (NULL) (82.198.197.8)
>
>
> After adjusting a matching rule of an attribute ldapsearch for existing
> attribute values returns unexpected results.
Making such changes requires the DB to be reloaded. This is not a 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/
Full_Name: Arvid Requate
Version: 2.4.35
OS: Debian / UCS
URL: http://apt.univention.de/download/temp/openldap/
Submission from: (NULL) (82.198.197.8)
After adjusting a matching rule of an attribute ldapsearch for existing
attribute values returns unexpected results. As an example the log file and the
script provided in the URL show what happened:
A) Start with the normal inetorgperson.schema.
1. create a inetOrgPerson object with and uppercase string in "carLicense"
2. search for the attributes in with different filters (normal and extensive
matching)
3. change the EQUALITY matching rule for that attribute from caseIgnoreMatch to
caseExactMatch (either in slapd.conf and restart or in cn=config without
restart).
4. search again.
Expected result A.1: the normal search for the uppercase value should return the
value
The log file shows: the search for the uppercase value returns no result
Expected result A.2: the normal search for the lowercase value should return no
result
The log file shows: the search for the lowercase value returns a result
The same holds for the extensible :caseExactMatch: search.
B) The second, morempreressive, inverse test shows that this behaviour depends
on the matching rule that was in place at the time the obejct gets created:
Starting now with a caseExactMatch EQUALITY matching rule for "carLicense" I
repeat the test above:
1. create a inetOrgPerson object with and uppercase string in "carLicense"
2. search for the attributes in with different filters (normal and extensive
matching)
3. change the EQUALITY matching rule for that attribute from caseExactMatch to
caseIgnoreMatch (either in slapd.conf and restart or in cn=config without
restart).
4. search again.
Expected result B.1: the normal search for the uppercase value should return the
value
The log file shows: the search for the uppercase value returns no result
Expected result B.2: the normal search for the lowercase value should return the
value
The log file shows: the search for the lowercase value returns no result
Expected result B.3: the :caseIgnoreMatch: extensible filter should find the
value
The log file shows: the search for the lowerca v value returns no result
The provided shell script works by changing the schema directly via cn=config,
but the same results can be found when using static configuration+schema files
and restarting slapd after each schema modification.
No index was configured for the "carLicense" attribute and a bdb backend was
used. See the cn=config.ldif provided.
ryan(a)nardis.ca wrote:
> On 08/09/14 01:30 PM, quanah(a)zimbra.com wrote:
>> Schema filenames should only be alphanumeric. Noted to update the
>> documentation with this restriction.
>
> OK, noted. Even so, please consider a change along the lines of
> <http://paste.debian.net/119969/>, just to avoid crashing on an
> inappropriate filename.
Patched in master, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On 08/09/14 01:30 PM, quanah(a)zimbra.com wrote:
> Schema filenames should only be alphanumeric. Noted to update the
> documentation with this restriction.
OK, noted. Even so, please consider a change along the lines of
<http://paste.debian.net/119969/>, just to avoid crashing on an
inappropriate filename.
--On Monday, September 08, 2014 7:03 PM +0000 ryan(a)nardis.ca wrote:
> Full_Name: Ryan Tandy
> Version: master, RE24
> OS: Debian
> URL:
> Submission from: (NULL) (24.68.121.206)
>
>
> Hi,
>
> Debian bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603544
Schema filenames should only be alphanumeric. Noted to update the
documentation with this restriction.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: Ryan Tandy
Version: master, RE24
OS: Debian
URL:
Submission from: (NULL) (24.68.121.206)
Hi,
Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603544
Steps to reproduce:
ln -s /usr/local/etc/openldap/schema/core.schema core+test.schema
echo 'include ./core+test.schema' > slapd.confA0Amkdir slapd.d
slaptest -f slapd.conf -F slapd.d
Before commit d1b38bd ("ITS#6967 normalize schema RDN"), this fails with:
config_build_entry: build "cn={0}core+test" failed: "(null)"
backend_startup_one (type=config, suffix="cn=config"): bi_db_open failed! (-1)
but slapd still works if running with slapd.conf only (-F omitted).
After that commit, slaptest and slapd both crash shortly after rdnNormalize at
bconfig.c:6841. rdnNormalize() fails because the constructed DN is not valid,
but its return value is not checked.
It would be really nice if it would automatically escape or replace
inappropriate characters in the filename, but I'll understand if that's asking
too much. :)
(Alternatively, if there are restrictions on what is considered a valid schema
filename, please document them.)