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".

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!

...

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.

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

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.

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.

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.

Are they used by any overlays/backends?

Not sure I got the point.

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 ------------------------------------------