[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: commit: ldap/doc/man/man5 slapd.access.5
- To: kurt@OpenLDAP.org, OpenLDAP Devel <openldap-devel@OpenLDAP.org>
- Subject: Re: commit: ldap/doc/man/man5 slapd.access.5
- From: Pierangelo Masarati <ando@sys-net.it>
- Date: Sat, 19 Mar 2005 18:55:43 +0100
- In-reply-to: <200503191746.j2JHk7wc085018@cantor.openldap.org>
- References: <200503191746.j2JHk7wc085018@cantor.openldap.org>
- User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
kurt@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/doc/man/man5
Modified Files:
slapd.access.5 1.57 -> 1.58
Log Message:
Document partially implemented "disclose" level.
"manage" remains undocumented (and unimplemented).
I was documenting "disclose" in slapd.access(5) but I never committed it
because it's only partially implemented in back-bdb (while, for
instance, it's completely implemented in back-sql). The main reason I
didn't finish implementing "disclose" in back-bdb is that back-bdb's
code is still a bit hairy, thus requiring extra effort and/or code
duplication to trap all the error cases. The essential point in
implementing "disclose" is that every error condition that may lead to
disclosure is subjected to an extra ACL checking so that (in meta-code)
if (error) {
if (about to disclose && can't dislcose) {
err = noSuchObject
}
// ... handle error
}
I'm concerned about "can't disclose" which needs an entry to apply to,
and, as such, it could incur in deadlocks because usually, when checking
errors, the entry has already been returned to the cache. As such, we
might need to heavily rework error handling all over back-bdb (and I
might not be familiar enough with the code).
Note that implementing "disclose" in searches only may be pointless,
because most of the other operations are candidate to disclosing entry
existence as well.
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497