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.
