4:28 a.m.
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:16 a.m.
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(a)sys-net.it
-----------------------------------
11:22 a.m.
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
5270
days inactive
5270
days old
2 comments
3 participants
participants (3)
-
Hallvard B Furuseth -
Howard Chu -
Pierangelo Masarati