[Date Prev][Date Next]
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: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
Kurt D. Zeilenga wrote:
However, "disclose on error" (disclose) andTo clarify:
"don't disclose on error" (none) can be implemented now in
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,
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.
has to determine, for each piece of information to be returned,
whether the user is authorized to have that information
disclosed to it.
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.
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.
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
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497