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

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

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.

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.


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 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. Similar considerations seem to apply to most of the write operations.

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.

p.



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