Re: (ITS#3472) return code should be 32 when no access to object

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:18 AM 1/13/2005, Pierangelo Masarati wrote:
>Kurt D. Zeilenga wrote:
>
>>At 05:33 AM 1/11/2005, Pierangelo Masarati wrote:
>> 
>>
>>>Kurt D. Zeilenga wrote:
>>>
>>>   
>>>
>>>>However, "disclose on error" (disclose) and
>>>>"don't disclose on error" (none) can be implemented now in
>>>>backends.
>>>>     
>>>To clarify:
>>>   
>>
>>I'm not sure your clarification helps.
>>
>>First, with this new functionality, nothing should be changed
>>outside of error handling.  When an error does occur,
>> 
>not just in case of error; consider the case of plain search.  If one has no permissions on the entire database, whatever search will result in no searchEntry results, but in a successful result.  This means that at least the baseObject exists, but one doesn't have any access to it or to any of its subordinate objects.  This is not an error, but yet requires some disclose access checking.  I'd favor the idea of turning this case into an error, noSuchObject.  Moreover, the data that's returned, e.g. a matchedDN, a referral and so should be subjected to disclose access.

Maybe we need to require "search" on baseObject ("entry"),
so we get an error.  Then we can use "disclose" permission to
determine what error information to return.

>>then one
>>has to determine, for each piece of information to be returned,
>>whether the user is authorized to have that information
>>disclosed to it.
>Of course we need to make sure we're not defeating the purpose the other way: if real noSuchObject cases always return a matchedDN, and access-related noSuchObject cases don't, its absence would be a clear indication that it is very likely that the object is very likely to exist.

One can resolve this by returning the DN of the nearest
disclosable superior, but that's expensive to determine.

>>If the information pertains to an attribute type, then we
>>need to look at "disclose" on the attribute type.   If
>>the information pertains to the name of some entry (the
>>target or nearest superior), then we need to look at
>>"disclose" on that entry.
>Well, in principle I'd agree, but this defeats the purpose of disallowing disclosure about the existence of an object, not just a value.

If the user has disclose on an attribute type but not on "entry",
then the user has partial disclose permission on the object.  But...

>If one wants to hide the existence of an object, operations like compare, which only check about permissions for a specific attribute:value would allow to determine the existence of an object, based on the returned code; returning noSuchAttribute if dislose is not granted on the attribute implies that the object exists.

For compare, one could first check disclose on the attribute,
and, if not, also disclose on the entry.

>Similar considerations seem to apply to most of the write operations.

But for modify (and modrdn), this gets nasty.  Hence, maybe we just
want to have entry level disclose permissions...

>I'll wrap my recent changes into some #define SLAP_HONOR_DISCLOSE flag, so we can experiment a bit without impacting too much the rest of the development.

We're certainly going to have to toy with this a bit....


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