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

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

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

(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).