[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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 <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.