Re: browse permission in the ACM

[robert byrne <robert.byrne@Sun.COM>]

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 <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.