[Pkg-openldap-devel] Bug#864719: Bug#864719: Bug#864719: Bug#864719: Bug#864719: slapd: fails to configure when olcSuffix contains a backslash-escaped umlaut

[Ryan Tandy]

On Wed, Jun 14, 2017 at 09:06:20PM +0200, Karsten Heymann wrote:
>1. There is already code in openldap that maps dn's to paths in the
>cn=config backend when it writes the config tree to the file system in
>/etc/ldap/slapd.d. Maybe that code or at least its escaping logic can
>be reused.

There is. It uses \ as an escape character, which is likely to expose 
more bugs like this one, but that's probably a good thing as those are 
just lurking right now.

I'm more inclined to delete unsafe characters outright than escape them, 
I think, or maybe replace them with - or some other placeholder.

>2. Wouldn't it be enough to use the database *number* to uniquely name
>the database backup? This would remove the whole problem.
>3. In order to use the basedn as a file name that can be safely used
>in shell script, what about a whitelist approach that replaces or
>encodes any character that is not a (ascii) letter, number, dash or
>underscrore with something safe/sane? Seems a better way than the
>approach where only certain "bad" characters are replaced. Unicode is
>huge, and using a whitelist of known good characters seems a more
>defensive approach, especially when prefixed with the database number.
>So "o=|\/|y Über Company" would become something like
>"db2-yberCompany".

I've thought about both of these, and indeed I think I'm converging on 
something like your last suggestion in order to maintain some kind of 
tradeoff between robustness and readability. The tricky parts are 
guaranteeing uniqueness (in case of two suffixes normalizing to the same 
string), and ensuring upgrades still work when the algorithm changes 
(the old algorithm needs to be kept, and used as a fallback if an 
expected file isn't found).

I already intended to change the maintainer scripts to process databases 
using the number as the key, instead of the suffix. This is just another 
reason to move in that direction.

SMOP and tuits as usual...

Thanks to both of you for the thoughts and suggestions.