Howard Chu writes:
Modified Files: slapd-bdb.5 1.38 -> 1.39 Support DB encryption
When this topic was first raised, I thought it was pretty useless: (...)
I can think of reasons to use it:
- Protecting data on the machine itself, if it gets stolen or carelessly sold. I don't know much about how that works though, in particular if one wants slapd to come up at reboot. Store the key physically in a different place, on a remote filesystem?
Data even from deleted files can be extracted. OS calls to wipe files when deleting them help, but I'm not sure if those are a guarantee that the data can't be recovered.
- Machines and OpenLDAP are quite fast nowadays. Enough so that speed may be less important to an admin than keeping backup routines as simple as possible. Or having as small exceptions as possible from site-wide practice, since DB backup needs an exception in any case.
Still, a flag which might be more useful is DB_CHKSUM, as described in "Berkeley DB Reference Guide: Berkeley DB recoverability" http://www.oracle.com/technology/documentation/berkeley-db/xml/ref/transapp/... Could offer options to (a) not use it, (b) use it when the filesystem block size differs from the DB file size, and (c) always use it. Except, I wonder if there is a good reason why this isn't already a DB_CONFIG option.