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.)
Comments?
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 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.)
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.
My 2c.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Howard Chu writes:
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.
This sounds equivalent to a control, but in a more convenient format Which sounds good to me, but I think this should be visible from the attribute name and maybe OID arc. E.g. names starting with 'olcCtrl'.
I'm not quite sure why not persist it, however. auto-mkdir during a possibly failed attempt to load a config would be excessive, but the mkdirs could be delayed until the new database is opened.
Actually, there could be an ;openldap-ephemeral option which (if supported for an attribute+backend) would prevent it from being stored.
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.)
Well, I still think that "of course" part would make more sense if it was reversed. A small metaconfig file outside slapd, which would be unavailable or read-only under cn=config. Though that doesn't preclude another meatconfig level which can be written via cn=config.
-
Hallvard B Furuseth -
Howard Chu -
Pierangelo Masarati