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

Re: (ITS#4770) monitoringslapd.sdf patch



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