[Date Prev][Date Next]
Re: ITS#4829, creating olcDbDirectory
Howard Chu 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
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,
Sounds interesting; I think in general there should be:
a) the possibility to disable such type of operations, not modifiable
via back-config; if enabled,
b) the possibility to disable, modifiable via back-config; if enabled,
c) a means to allow the operation (the one you propose).
This could apply to a broad class of operations that are required by
specific back-config operations via protocol, but should not be allowed
by default because of potentially risky side-effects.
Best would be to have this with granularity: allow it for certain
operations based on some criteria (for a database: the backend type, the
naming context, the value of the path, ...)
This would allow overly paranoid admins to disable everything (a); or,
to protect those privileges using ACLs in systems with multiple
identities allowed to configure the service (b).
As per how to wisely implement (a), well, it could be done using a
read-only attribute in the global section. Then, to change it, one
would need to stop the service and manually edit the corresponding LDIF.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497