[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 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
-----------------------------------