Subject: Re: browse permission in the ACM

From: [email-masked] (Richard V Huber)
Date: Wed, 25 Apr 2001 16:45:19 -0400

Do you mean this as a general statement or specifically for
extensibleMatch?  If it is a general statement, is there really any
remaining use for the "b" permission?

Rick Huber

: From: robert byrne <[email-masked]>
: To: Richard V Huber <[email-masked]>
: CC: [email-masked]
: Subject: Re: browse permission in the ACM
: 
: Rick,
: 
: I agree that this needs clarification.  To be on the safe side my
: suggestion would be to require a filter permisison check on the dn
: attributes being matched.  For simplicity I would make it independent of
: the scope.  So, for non-base entries we would test "b" _and_ the
: required filter permissions, while for base entries we would just test
: the filter permissions.
: 
: Rob.
: 
: Richard V Huber wrote:
: > 
: > This email is carrying around a lot of history.  I've clipped off some
: > of the earlier messages in the chain.
: > 
: > My concern about extensibleMatch and option 3 was based on this
: > paragraph from the draft (from Section 5.2, item 2):
: > 
: >       The above statement covers the case where the
: >       attributes are being evaluated as part of an
: >       extensibleMatch (RFC 2251 section 4.5.1) which appears
: >       in the filter.  In the case where the dnAttributes
: >       field of the extensibleMatch is true then we do not
: >       require any access checks to the attributes of the dn
: >       candidateDN as access to these is taken to be granted
: >       by the "b" permission, which has already been required
: >       above.
: > 
: > Since Option 3 implies that the "b" permission is NOT required for the
: > base object to be searched, you might want to change 5.2 item 2 to
: > say that "r" and "s" permissions ARE required for extensibleMatches on
: > the DN of the base object.  But given that the "t" permission exists,
: > this may not really matter in real-life situations.
: > 
: > Rick Huber
: > 
: > : From: robert byrne <[email-masked]>
: > : To: Richard V Huber <[email-masked]>
: > : CC: [email-masked]
: > : Subject: Re: browse permission in the ACM
: > :
: > : Richard V Huber wrote:
: > : >
: > : > As I understand Option 3, it says that the "b" permission is not
: > : > checked on the base object of a search.
: > : >
: > : > I'm trying to figure out what permissions would be checked for the base
: > : > object under option 3.  For example, item 1 in section 5.2 would not
: > : > seem to apply when the candidateDN is the base object.  How about the
: > : > part of item 2 that discusses extensibleMatch?
: > :
: > : The idea is that "b" gives you the right to find an entry using the
: > : subtree and onlevel options of search.  For a base entry, we do not
: > : require "b" because you have named it.  We would still require the other
: > : permissions (filter, returnDn, readOnAttribute) for a base entry.  Where
: > : we refer to "b" in those sections we should say something like "as per
: > : item 1."--ie. we never require "b" on base entries.
: > :
: > : >
: > : > One of the reasons I had not responded to your previous email is that
: > : > I'm still trying to figure out whether these questions really matter in
: > : > practical directories.
: > :
: > : Good question--I agree the effect is a bit subtle and not obviously a
: > : mandatory feature.  It's another level of granularity of control on
: > : search.  I think you can see a similar effect in the Unix file system
: > : where you can be in a directory and type "ls" and see nothing but if you
: > : do, say, "cd public_html" you will find yourself in that directory, if
: > : you have the appropriate rights.  In LDAP, you might want to have a
: > : subtree with resources users can query if they know about them, but not
: > : be able to discover resources "easily".
: > :
: > : At Pittsburg people seemed to like the browsing idea and I agreed to
: > : propose something.
: > :
: > : Rob.
: > :
: > : >
: > : > Rick Huber
: > : >
: > : > : Sender: [email-masked]
: > : > : From: robert byrne <[email-masked]>
: > : > : To: [email-masked]
: > : > : Subject: Re: browse permission in the ACM
: > : > :
: > : > :
: > : > : All,
: > : > :
: > : > : By way of a partial conclusion of this thread, for the next draft I
: > : > : intend to propose 3. below.
: > : > :
: > : > : Rob.

---

From: robert byrne <[email-masked]>
Date: Thu, 26 Apr 2001 12:27:58 +0200

> remaining use for the "b" permission?

I mean specifically for the extensible match when dnAttributes is set to
True ie. you have explicitly requested matching on the dn attributes.

I suspect you are right though that it would be hard in reality to
demonstrate the difference in requiring match permissions on the dn
attributes and just relying on the "t" permission and aliasing.  However
the following example shows the type of situation that makes me think it
might be better to require match permission testing on the dn
attributes:

	o=sun.com
	|
	ou=eng
	|
	cn=rob,ou=eng,o=sun.com  (aliased to cn=support,o=sun.com)

Then if a user with zero rights does a base search at
cn=rob,ou=eng,o=sun.com and specifies an extensible match with
dnAttributes set to true on say the ou attribute, then if that match
matches (say it was just a presence test) then from an access control
point of view the server is authorized to return the alaised dn.  So a
user with zero rights has guessed an entry and has had the server
confirm that that entry exists.  If we require match testing on the ou
attribute of the dn then as that right is absent the discloseOnError
stuff kicks in to hide the entry--he would get back "noSuchObject".

I guess you can summarize that by saying "for base objects of seaches
which are aliased we are relying on filter matching protection to
protect the entry".  Or to state it another way, "s" permission on an
attribute of an aliased entry (or on a naming attribute in the entry's
dn) is enough to enable you to confirm that entry's existence.

Rob.