db encryption/checksum (was: commit: ldap/doc/man/man5 slapd-bdb.5)

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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/reclimit.html
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.

-- 
Hallvard