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

Re: commit: ldap/doc/man/man5 slapd.access.5



At 09:55 AM 3/19/2005, Pierangelo Masarati wrote:
>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).

I committed it so that folks might start playing with (actually,
they are as "none" doesn't imply disclose on error anymore).

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

And that's only a small part of "don't disclose".  For instance,
return of the matched DN needs to checked.

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

Yes, it needs to be implemented across the board.



>p.
>
>
>   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497