Re: browse permission in the ACM

[rvh@qsun.mt.att.com (Richard V Huber)]

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 <robert.byrne@Sun.COM>
: To: Richard V Huber <rvh@qsun.mt.att.com>
: CC: ietf-ldapext@netscape.com
: 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: Robert.Byrne@Sun.COM
: > : From: robert byrne <robert.byrne@Sun.COM>
: > : To: ietf-ldapext@netscape.com
: > : 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.