Re: (ITS#8507) adding the syncprov overlay does not load the associated schema elements
by elecharny@gmail.com
Le 12/10/16 à 02:40, Ryan Tandy a écrit :
> On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote:
>> $ grep -ri "olcSpNoPresent" slapd.d
>> $ ...
>>
>> You can stop and restart the server, the attribute is still not present.
>
> It's system schema and not user schema, so I kind of expect this. The
> behaviour is the same when cn=config is initialized using slapadd -n0.
>
> 'ldapsearch -s base cn=schema,cn=config' does show these attributes.
>
>> Going back to the slapd.conf file, add the module :
>>
>> ...
>> # Uncomment the mululeloads as needed to enable additional
>> # functionalityi when configured. NOTE: We package many
>> # more modules options than those found below.
>> moduleload back_mdb.la
>> moduleload back_monitor.la
>> moduleload syncprov.la # Added module
>> ...
>>
>> and regenerate the slapd.d content :
>>
>> $ /etc/init.d/solserver stop
>> $ rm -rf /opt/symas/etc/openldap/slapd.d/*
>> $ /opt/symas/bin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F
>> /opt/symas/etc/openldap/slapd.d
>> $ grep -ri "olcSpNoPresent" /opt/symas/etc/openldap/slapd.d
>> slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgOvAt:1.3 NAME
>> 'olcSpNoPresent' DESC 'Omit Present
>> slapd.d/cn=config/cn=schema.ldif: $ olcSpSessionlog $ olcSpNoPresent $
>> olcSpReloadHint ) )
>> $...
>>
>> This is problematic...
>
> If there is a bug, I'd say it's the fact that the converter does write
> out these attributes.
>
> Actually slapd replaces the entire cn=schema entry at runtime. As far
> as I can tell, the the cn=schema.ldif file on disk is never used. So
> it would certainly be dangerous to rely on its contents for anything.
I must say that I can't reproduce this behavious with the latest
release, so I guess it was fixed since the test I did.
4 years, 3 months
Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ryan@nardis.ca
Just noting that one way to reproduce this assert reliably is to bind to
an existing entry, through the relay, with an incorrect password.
The important part of the config is:
database mdb
suffix dc=example,dc=com
[...]
overlay ppolicy
database relay
suffix o=example
overlay rwm
rwm-suffixmassage o=example dc=example,dc=com
overlay ppolicy
Then, binding through the relay:
$ ldapwhoami -x -D uid=test,o=example -w zzz -e ppolicy
slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed.
Same as when someone accidentally attaches two ppolicy instances to a
single database. Not totally sure, but I suspect it's wrong here too: I
don't see what the ppolicy attached to the relay is supposed to add in
this case. I guess in theory they could have different configuration?
wrt. e.g. ppolicy_use_lockout, or even pwdLockout/pwdMustChange via a
different ppolicy_default...
Wondering if it would make sense for add_passcontrol to look for a
ppolicy control already existing on the op, and try to fail gracefully
if so, instead of hitting this on the way out.
Binding to the same entry with the correct password...
$ ldapwhoami -x -D uid=test,o=example -w test -e ppolicy
currently hits the same segfault reported in ITS#7966.
4 years, 3 months
Re: (ITS#8507) adding the syncprov overlay does not load the associated schema elements
by ryan@nardis.ca
On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote:
>$ grep -ri "olcSpNoPresent" slapd.d
>$ ...
>
>You can stop and restart the server, the attribute is still not present.
It's system schema and not user schema, so I kind of expect this. The
behaviour is the same when cn=config is initialized using slapadd -n0.
'ldapsearch -s base cn=schema,cn=config' does show these attributes.
>Going back to the slapd.conf file, add the module :
>
>...
># Uncomment the mululeloads as needed to enable additional
># functionalityi when configured. NOTE: We package many
># more modules options than those found below.
>moduleload back_mdb.la
>moduleload back_monitor.la
>moduleload syncprov.la # Added module
>...
>
>and regenerate the slapd.d content :
>
>$ /etc/init.d/solserver stop
>$ rm -rf /opt/symas/etc/openldap/slapd.d/*
>$ /opt/symas/bin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F
>/opt/symas/etc/openldap/slapd.d
>$ grep -ri "olcSpNoPresent" /opt/symas/etc/openldap/slapd.d
>slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgOvAt:1.3 NAME
>'olcSpNoPresent' DESC 'Omit Present
>slapd.d/cn=config/cn=schema.ldif: $ olcSpSessionlog $ olcSpNoPresent $
>olcSpReloadHint ) )
>$...
>
>This is problematic...
If there is a bug, I'd say it's the fact that the converter does write
out these attributes.
Actually slapd replaces the entire cn=schema entry at runtime. As far as
I can tell, the the cn=schema.ldif file on disk is never used. So it
would certainly be dangerous to rely on its contents for anything.
4 years, 3 months
Re: (ITS#8510) OpenLDAP Crash when using ppolicy
by ryan@nardis.ca
Hi,
On Mon, Oct 03, 2016 at 08:00:55AM +0000, poil(a)quake.fr wrote:
>I have an openldap with a master-master replication
>* Config directory is a HDB database
>* Main directory (people/group/policy) is a MDB database
>
>When using
># ldapwhoami -x -H ldap://localhost -D uid=poil,ou=opople,dc=my,dc=test -W -e
>ppolicy
>LDAP crash
>
>When using
># ldapwhoami -x -H ldap://localhost -D uid=poil,ou=people,dc=my,dc=test -W
>It's working
There isn't enough information here to reproduce the issue. Please
provide complete steps to reproduce starting from a clean installation,
including the entire configuration and some example data that
demonstrates the problem.
4 years, 3 months
Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny@gmail.com
Le 11/10/16 à 19:56, Hallvard Breien Furuseth a écrit :
> On 11. okt. 2016 18:10, elecharny(a)apache.org wrote:
>> IMO, the code that deal with tags in the lber decode.c
>> ber_tag_and_rest() method
>> is incorrectly decoding tags that are longer than 1 byte. (...)
>
> It's far too late to change the ASN.1 <-> integer mapping. liblber is
> widely used outside OpenLDAP, we don't know if we'd break something.
I think I overlooked the origial code. See later...
>
> As lber.h explains:
> * ber_tag_t represents the identifier octets at the beginning of BER
> * elements. OpenLDAP treats them as mere big-endian unsigned integers.
Indeed. That means the method just grabs bytes without taking care of
the 'continuation' bits (ie the 7th bit if there are more bytes after),
and returns a long.
>
> I wish it had at least used little-endian so we could check the class
> and P/C bits with a simple '&' operation. Oh well.
Well, the way this function works make it hard to do so, I agree. OTOH,
it means this ITS can be closed, because it's based on a wrong
understanding on what this method does. It's not bugy, it's just doing
somethig different than what I was expecting.
Thanks !
4 years, 3 months
Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by h.b.furuseth@usit.uio.no
On 11. okt. 2016 18:10, elecharny(a)apache.org wrote:
> IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method
> is incorrectly decoding tags that are longer than 1 byte. (...)
It's far too late to change the ASN.1 <-> integer mapping. liblber is
widely used outside OpenLDAP, we don't know if we'd break something.
As lber.h explains:
* ber_tag_t represents the identifier octets at the beginning of BER
* elements. OpenLDAP treats them as mere big-endian unsigned integers.
I wish it had at least used little-endian so we could check the class
and P/C bits with a simple '&' operation. Oh well.
--
Hallvard
4 years, 3 months
(ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny@apache.org
Full_Name: Emmanuel Lecjarny
Version: 2.4.44
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (90.92.161.247)
IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method
is incorrectly decoding tags that are longer than 1 byte. Not that it is a huge
problem for OpenLDAP, because we always use 1 byte long tags, but from the ASN.1
BER decoding POV, that wilbrbreak when having a 2 bytes long tag :
116 do {
117 if ( rest <= 0 ) {
118 break;
119 }
120 tag <<= 8;
121 tag |= *ptr++ & 0xffU;
122 rest--;
123
124 if ( ! (tag & LBER_MORE_TAG_MASK) ) {
125 goto done;
126 }
127 } while ( tag <= (ber_tag_t)-1 / 256 );
should read
114 tag = (ber_tag_t) 0x00U;
115
116 do {
117 if ( rest <= 0 ) {
118 break;
119 }
120 tag <<= 7;
121 tag |= *ptr++ & 0x7fU;
122 rest--;
123
124 if ( ! (tag & LBER_MORE_TAG_MASK) ) {
125 goto done;
126 }
127 } while ( tag <= (ber_tag_t)-1 / 256 );
The reason being that BER encoding for Tags when longer than 1 byte looks like
:
[class|P/C|11111] - [1|uuu uuuu] - [1|uuu uuuu] - [1|uuu uuuu] - ... - [0|uuu
uuuu]
byte 1 byte 2 byte 3 byte 4 byte
N
and the 'uuu uuuu' parts are only 7 bits long.
4 years, 3 months
Re: (ITS#8515) => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by michael@stroeder.com
sebastiaan.van.zanten(a)ing.nl wrote:
> Version: 2.4.4
^^^^^
Sure?
> However we installed it as an MDB database
> and now we receive the following error:
>
> => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize
> limit reached (-30792)
>
> Apparently the settings were default and it exceeded the size of 10mb. We have
> plenty of diskspace on the machine. However we are unsure how to update this.
> Can you advise us how we do this?
In general usage questions should not be added as ticket. Please use the
openldap-technical mailing list instead.
In your case you can increase the DB size with the slapd.conf directive
"maxsize" (or the equivalent attribute when using cn=config) and restart slapd.
Ciao, Michael.
4 years, 3 months
(ITS#8515) => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by sebastiaan.van.zanten@ing.nl
Full_Name: Sebastiaan van Zanten
Version: 2.4.4
OS: Redhat 6.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (145.221.52.104)
Dear Sir/Madam,
We are using openldap as an overlay between our corporate ldap and some other
tooling (gitlab, artifactory, etc). However we installed it as an MDB database
and now we receive the following error:
=> mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize
limit reached (-30792)
Apparently the settings were default and it exceeded the size of 10mb. We have
plenty of diskspace on the machine. However we are unsure how to update this.
Can you advise us how we do this?
Kind Regards,
Sebastiaan van Zanten
4 years, 3 months