Re: denyop (Was: commit: ldap/servers/slapd/back-monitor back-monitor.h database.c init.c proto-back-monitor.h)

[Pierangelo Masarati <ando@sys-net.it>]

Kurt D. Zeilenga wrote:

> As I noted in denyops discussions, we should allow the
> restrict op flags to be individually set.  That is,
> 'readonly on' should be complemented by:
>        denyop modify
>        denyop rename
>        denyop delete
>        denyop add
>
> If we do that, then it seems odd to have readOnly boolean
> in back-monitor.  Maybe we should have a multi-valued
> attribute instead:
> denyop: modify
> denyop: compare
> denyop: 1.3.6.1.4.1.4203.1.11.1
>
> (the last is food for thought)
>  
I would separate the two issues based on the context they may be used.
This would clarify that both attributes (at least both principles) are
useful.  The "denyop" approach should be intended as a means to
fine tuning what operations a database can be used for; the "readOnly"
apporach would be rather administrative, i.e. used by an administrative
entity to operate temporary mode changes, e.g. right before changing
the configuration in a way that requires disabling of write operations
(e.g. the schema is being changed, a replica is being added or so).

In this sense, "denyop" would be nearly permamnent, and fine tuning
is desirable; "readOnly" would be mostly temporary, and coarse but
quick'n'easy write disabling would be preferable.  In this sense I'm in
favour of a multi-valued "denyOp" attribute, plus a boolean "readOnly"
that, when set, overrides the write "denyOp" values (simply, it's honored
before "denyOp" is checked).

Ando.