----- "Howard Chu" hyc@symas.com wrote:

I thought I had a good idea for this, although upon further reflection it still has holes. But it may still be a good starting point for discussion:

For backends that support the olcDbDirectory keyword, we should also define a write-only olcDbMkdir attribute. If it's provided when ldapadd'ing an

olcDatabase entry, or when ldapmodifying, then its values are treated as pathnames that we will attempt to create before processing any other parts of the request. This attribute would not be persisted in the cn=config backing store, so it will only take effect on dynamic operations, not when reloading the config on a subsequent startup.

If the target directory already exists and is owned by the current uid, then it's a no-op. If the owner doesn't match, or the target pathname is not a directory, the request will fail. Otherwise, we try the mkdirs and proceed if they succeed. No cleanup will be performed on a failure - it would be pretty rude to "rm -rf" an existing database here.

It may still be worthwhile to provide a global setting defining the filesystem locations that are allowed to be used. (Of course, anyone with back-config's rootdn credentials can set it to anything they want, anyway.)

So if slapd is run as root, the uid is 0 then the olcDbMkdir can create a dir anywhere on the file system? The obvious thing to do there then is not run slapd as root and as an ldap user and make this very clear in the docs.