Re: (ITS#4770) monitoringslapd.sdf patch

[ghenry@suretecsystems.com]

<quote who="ando@sys-net.it">
> Gavin Henry wrote:
>> <quote who="Pierangelo Masarati">
>>> Gavin,
>>>
>>> from the preamble, one may infer that monitoring is optional in the
>>> sense it can be optionally built.  That's how it used to be;
>>
>> In 2.3. I see. Thanks.
>>
>>> however, in
>>> 2.4, it is always enabled, but it still must be explicitly exposed in
>>> slapd.conf/slapd.d by using "database monitor".
>>
>> Ah, understood.
>>
>>> I would replace
>>> "enabled" with "exposed", and possibly explicitly indicate that in 2.4
>>> it is no longer an option to build the monitor interface.
>>
>> Yes, that sounds fine.
>>
>>> No global directive should occur after "database monitor", as it
>>> represents a database instantiation like any other.  Although most
>>> global directives wouldn't complain if appearing __after__ a database
>>> instantiation, such use should be considered at least "bad practice".


Understood.

>>
>> OK. But I was right with the fact you can put rootpw directly beneath
>> it,
>> or  is that what you are saying about bad practices?
>
> "rootdn" and "rootpw" are per-database directives.  They __have__ to go
> there.  What I call "bad practice" is, say, putting a "threads"
> directive inside a database.  It will be handled as expected, i.e. it
> impacts the whole instance of slapd, but it appears like it were for
> that database only!

Ah yes! ;-) Agreed and now understood.

>
>>> About access control, it may be worth stressing that some attributes
>>> can
>>> actually be written; this requires to protect them and, at the same
>>> time, to grant the desired identities write privileges on them.
>>
>> Only with the rootpw defined?
>
> back-monitor honors access control much like any other database (at
> least it should; if it doesn't, then it's a bug).
>
> So any ACL applies (should apply) and as such there's much freedom in
> defining who has access to what under which circumstances.  So I don't
> see any need to write any specific information about access control, as
> soon as the administrator is warned that access control needs to be
> taken into account for that database as well.

OK.

>
>> If so;
>>
>> What attributes can be written to?
>
> AFAIR: managedInfo and derived attrs are writable; practically, they can
> only be written whenever a modify hook is defined for that subsystem,
> and constraints may be present.
>
> managedInfo can be written in "cn=Log,cn=Monitor" but it can only take
> the values that are allowed as loglevels (see loglevel in slapd.conf(5),
> but note that in HEAD, and possibly in 2.3 as well, I don't remember,
> modules can add further log levels).

OK. This should be all documented! ;-)

>
> readOnly can be written in each database entry (those residing below
> "cn=Databases,cn=Monitor")
>
> I'm not sure there' any more in stock back-monitor; but beware that
> back-monitor can be extended by modules through an API, so there might
> be more.  In general, look for any modify hook in the definition of each
> subsystem.


Modules, as in overlays? That was what my last question was really asking.
For example, how accesslog is used by Delta-Syncrepl. I was merely trying
to understand if, when some other feature gets enabled, it relies on
back-monitor to work properly.

>
>> What are their purpose/effects?
>
> perform non-persistent state changes (i.e. changes that are not
> reflected in back-config and don't et to the persistent storage on disk
> when the system is arrested.

OK.

>
>> What ACL example can we show to protect them?
>
> I don't think anything relevant is needed; in case, something like
>
> # only let the manager rite managed info (add further modifiable attrs)
> access to attrs=managedInfo
> 	by dn.exact="cn=Manager" write
> 	by * read
>
> # only let the manager read connections data (may be sensible)
> access to dn.children="cn=Connections,cn=Monitor"
> 	by dn.exact="cn=Manager" read
> 	by * none
>
> # allow read access to anything else
> access to *
> 	by * read
>
> unless there's anything else worth protecting.

Looks standard enough.

>
>> Are they used by any overlays/backends?
>
> Not sure I got the point.

See my above comment regarding accesslog.

Thanks for your time.

Gavin.

>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.n.c.
> Via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ------------------------------------------
> Office:   +39.02.23998309
> Mobile:   +39.333.4963172
> Email:    pierangelo.masarati@sys-net.it
> ------------------------------------------
>
>
>