NAME¶
slapo-dds - Dynamic Directory Services overlay to slapd
SYNOPSIS¶
/etc/ldap/slapd.conf
DESCRIPTION¶
The
dds overlay to
slapd(8) implements dynamic objects as per RFC
2589. The name
dds stands for Dynamic Directory Services. It allows to
define dynamic objects, characterized by the
dynamicObject objectClass.
Dynamic objects have a limited lifetime, determined by a time-to-live (TTL) that
can be refreshed by means of a specific
refresh extended operation.
This operation allows to set the Client Refresh Period (CRP), namely the
period between refreshes that is required to preserve the dynamic object from
expiration. The expiration time is computed by adding the requested TTL to the
current time. When dynamic objects reach the end of their lifetime without
being further refreshed, they are automatically deleted. There is no guarantee
of immediate deletion, so clients should not count on it.
Dynamic objects can have subordinates, provided these also are dynamic objects.
RFC 2589 does not specify what the behavior of a dynamic directory service
should be when a dynamic object with (dynamic) subordinates expires. In this
implementation, the lifetime of dynamic objects with subordinates is prolonged
until all the dynamic subordinates expire.
This
slapd.conf(5) directive adds the
dds overlay to the current
database:
- overlay dds
-
The database must have a
rootdn specified, otherwise, the
dds
overlay will not be able to delete expired objects. The
dds overlay may
be used with any backend that implements the
add,
modify,
search, and
delete operations. Since its use may result in many
internal entry lookups, adds and deletes, it should be best used in
conjunction with backends that have reasonably good write performances.
The config directives that are specific to the
dds overlay are prefixed
by
dds-, to avoid potential conflicts with directives specific to the
underlying database or to other stacked overlays.
- dds-max-ttl <ttl>
- Specifies the max TTL value. This is also the default TTL newly created
dynamic objects receive, unless dds-default-ttl is set. When the
client with a refresh extended operation requests a TTL higher than it,
sizeLimitExceeded is returned. This value must be between 86400 (1 day,
the default) and 31557600 (1 year plus 6 hours, as per RFC 2589).
- dds-min-ttl <ttl>
- Specifies the min TTL value; clients requesting a lower TTL by means of
the refresh extended operation actually obtain this value as CRP. If set
to 0 (the default), no lower limit is set.
- dds-default-ttl <ttl>
- Specifies the default TTL value that newly created dynamic objects get. If
set to 0 (the default), the dds-max-ttl is used.
- dds-interval <ttl>
- Specifies the interval between expiration checks; defaults to 1 hour.
- dds-tolerance <ttl>
- Specifies an extra time that is added to the timer that actually wakes up
the thread that will delete an expired dynamic object. So the nominal
lifetime of the entry is that specified in the entryTtl attribute,
but its lifetime will actually be entryTtl + tolerance. Note that
there is no guarantee that the lifetime of a dynamic object will be
exactly the requested TTL; due to implementation details, it may be
longer, which is allowed by RFC 2589. By default, tolerance is 0.
- dds-max-dynamicObjects <num>
- Specifies the maximum number of dynamic objects that can simultaneously
exist within a naming context. This allows to limit the amount of
resources (mostly in terms of run-queue size) that are used by dynamic
objects. By default, no limit is set.
- dds-state {TRUE|false}
- Specifies if the Dynamic Directory Services feature is enabled or not. By
default it is; however, a proxy does not need to keep track of dynamic
objects itself, it only needs to inform the frontend that support for
dynamic objects is available.
ACCESS CONTROL¶
The
dds overlay restricts the refresh operation by requiring
manage access to the
entryTtl attribute (see
slapd.access(5) for details about the
manage access privilege).
Since the
entryTtl is an operational, NO-USER-MODIFICATION attribute,
no direct write access to it is possible. So the
dds overlay turns
refresh extended operation into an internal modification to the value of the
entryTtl attribute with the
relax control set.
RFC 2589 recommends that anonymous clients should not be allowed to refresh a
dynamic object. This can be implemented by appropriately crafting access
control to obtain the desired effect.
Example: restrict refresh to authenticated clients
access to attrs=entryTtl
by users manage
by * read
Example: restrict refresh to the creator of the dynamic object
access to attrs=entryTtl
by dnattr=creatorsName manage
by * read
Another suggested usage of dynamic objects is to implement dynamic meetings; in
this case, all the participants to the meeting are allowed to refresh the
meeting object, but only the creator can delete it (otherwise it will be
deleted when the TTL expires)
Example: assuming
participant is a valid DN-valued attribute, allow users
to start a meeting and to join it; restrict refresh to the participants;
restrict delete to the creator
access to dn.base="cn=Meetings"
attrs=children
by users write
access to dn.onelevel="cn=Meetings"
attrs=entry
by dnattr=creatorsName write
by * read
access to dn.onelevel="cn=Meetings"
attrs=participant
by dnattr=creatorsName write
by users selfwrite
by * read
access to dn.onelevel="cn=Meetings"
attrs=entryTtl
by dnattr=participant manage
by * read
REPLICATION¶
This implementation of RFC 2589 provides a restricted interpretation of how
dynamic objects replicate. Only the master takes care of handling dynamic
object expiration, while replicas simply see the dynamic object as a plain
object.
When replicating these objects, one needs to explicitly exclude the
dynamicObject class and the
entryTtl attribute. This
implementation of RFC 2589 introduces a new operational attribute,
entryExpireTimestamp, that contains the expiration timestamp. This must
be excluded from replication as well.
The quick and dirty solution is to set
schemacheck=off in the syncrepl
configuration and, optionally, exclude the operational attributes from
replication, using
syncrepl ...
exattrs=entryTtl,entryExpireTimestamp
In any case the overlay must be either statically built in or run-time loaded by
the consumer, so that it is aware of the
entryExpireTimestamp
operational attribute; however, it must not be configured in the shadow
database. Currently, there is no means to remove the
dynamicObject
class from the entry; this may be seen as a feature, since it allows to see
the dynamic properties of the object.
FILES¶
- /etc/ldap/slapd.conf
- default slapd configuration file
SEE ALSO¶
slapd.conf(5),
slapd-config(5),
slapd(8).
AUTHOR¶
Implemented by Pierangelo Masarati.