https://bugs.openldap.org/show_bug.cgi?id=9254
Bug ID: 9254 Summary: Datatypes boudary check on slapadd Product: OpenLDAP Version: 2.4.42 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: c.dosio@gmail.com Target Milestone: ---
The import of an LDIF file containing a passwordPolicy objectClass where the attribute pwdMaxAge was populated as 50000000000000 (while the max value of that attribute should be 315360000) went fine but any editing of values on that objectClass would make slapd hang until brutally killed (it goes into error 8 where apparently the operation is waiting to be executed, but even after several hours it would still be frozen). The only way I managed to solve the situation was to take e previous dump, change the value to something within the value's range, and restore it. BTW I couldn't manage to run slapcat (neither with the -c flag) to have a full dump.
There are three issues in my opinion:
1. Shouldn't slapadd make some checks on data type values and eventually either give an error or change an exceeding value to the minimum/maximum value of the range? 2. Shouldn't slapd manage the exceeding value instead of freezing (in a way coherent to point 1)? 3. Shouldn't slapcat be forced to skip over the problem of an out of range value at least if run with the "-c" flag?
https://bugs.openldap.org/show_bug.cgi?id=9254
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Datatypes boudary check on |Datatypes boundary check on |slapadd |slapadd
https://bugs.openldap.org/show_bug.cgi?id=9254
--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- Question, when you imported did you use slapadd or slapadd -q ?
https://bugs.openldap.org/show_bug.cgi?id=9254
--- Comment #2 from Claudio c.dosio@gmail.com --- I used the following syntax slapadd -n 1 -F /etc/ldap/slapd.d -l data_20200429.ldif
so without the "quick" flag
https://bugs.openldap.org/show_bug.cgi?id=9254
--- Comment #3 from Howard Chu hyc@openldap.org --- (In reply to Claudio from comment #0)
The import of an LDIF file containing a passwordPolicy objectClass where the attribute pwdMaxAge was populated as 50000000000000 (while the max value of that attribute should be 315360000) went fine but any editing of values on that objectClass would make slapd hang until brutally killed (it goes into error 8 where apparently the operation is waiting to be executed, but even after several hours it would still be frozen). The only way I managed to solve the situation was to take e previous dump, change the value to something within the value's range, and restore it. BTW I couldn't manage to run slapcat (neither with the -c flag) to have a full dump.
There are three issues in my opinion:
- Shouldn't slapadd make some checks on data type values and eventually
either give an error or change an exceeding value to the minimum/maximum value of the range?
slapadd generally does very few validity checks. It is intended to be used on LDIFs that are known to be valid, i.e. for loading the output of slapcat.
- Shouldn't slapd manage the exceeding value instead of freezing (in a way
coherent to point 1)?
Indeed, slapd shouldn't freeze. You should provide a gdb stack trace of the running threads when this situation occurs.
- Shouldn't slapcat be forced to skip over the problem of an out of range
value at least if run with the "-c" flag?
slapcat does no validity checks; it assumes the contents of the DB it is reading are valid. In most cases the -c flag is meaningless for slapcat.
https://bugs.openldap.org/show_bug.cgi?id=9254
--- Comment #4 from Claudio c.dosio@gmail.com ---
There are three issues in my opinion:
- Shouldn't slapadd make some checks on data type values and eventually
either give an error or change an exceeding value to the minimum/maximum value of the range?
slapadd generally does very few validity checks. It is intended to be used on >LDIFs that are known to be valid, i.e. for loading the output of slapcat.
This is correct if the dump were valid, in this particular case the dump contained an invalid data which then made instable slapd. Would it be possibile, maybe activating it by a flag, to add validity checks while importing? It could save from headaches further down the road. It took me quite a bit of time to pinpoint the problem to that value being out of bound
- Shouldn't slapd manage the exceeding value instead of freezing (in a way
coherent to point 1)?
Indeed, slapd shouldn't freeze. You should provide a gdb stack trace of the >running threads when this situation occurs.
I will try to give a gdb stack as soon as I can manage to replicate the problem on another PC (the one I fixed it on is being used).
- Shouldn't slapcat be forced to skip over the problem of an out of range
value at least if run with the "-c" flag?
slapcat does no validity checks; it assumes the contents of the DB it is >reading are valid. In most cases the -c flag is meaningless for slapcat.
In my particular case slapcat would stop at 32768 bytes and I have so send it a SIGKILL to close it. Probably the value is so much out of range that it gives problems also in reading it from the underneath DB. I left it for several minutes before killing the process.
What I will try to understand with my collegues is how that out of bound value has been accepted in the first place, or how it was forced.
https://bugs.openldap.org/show_bug.cgi?id=9254
--- Comment #5 from Ryan Tandy ryan@openldap.org --- If you actually are running 2.4.42, the slapd hang may be bug 7537, fixed in 2.4.43. Not sure about slapcat, that may be a separate bug, but please test a current release anyway.
Where did you get the number 315360000 from? As far as I know, OpenLDAP would accept any value that fits into a signed int.
The schema doesn't mention any min or max value for pwdMaxAge, so I think you can put any integer there. However, at runtime, if it (or any other parameter) can't be parsed as a signed int value, I think the whole policy is ignored (IIRC).
(side note: is signed int really correct for all of these? shouldn't a lot of them be unsigned...?)
-
openldap-its＠openldap.org