[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: browse permission in the ACM
Since Rob says `To minimize the number of combinations we also allow
the base element to be seen if "b" permission is assigned to it', it
seems that the new "b" includes the new "v" and is identical to the old
"b". So the real change here is the addition of the separate "v"
permission.
So I assume new the definitions of "b" and "v" in section 4.2.1 would
be something like (trying to stay reasonably close to the current
wording):
b BrowseDN
If granted, permits entries to be accessed using search operations
regardless of whether they explicitly provide the name of the entry.
v VertexDN
If granted, permits entries to be accessed using search operations
only if the name of the entry is explicitly supplied.
I guess my main question is whether the change is worth it. The model
is already rather complicated. Does this change provide value that is
worth the additional complexity? I'm not sure that it does.
And one other vaguely related question that came to mind after reading
Rob's email. He notes that "... the absence of a "v" or "b" permission
at any point does not abort the search operation as a whole or even on
a particular subtree."
I have been assuming (and this seemed like a good time to check) that
absence of a "t" permission DOES abort the search operation on a
particular subtree, since returning the DN of any object further down
in the tree would require that the DN of the object without "t"
permission be returned. Is that the generally accepted view?
Rick Huber
: Sender: Robert.Byrne@Sun.COM
: From: robert byrne <robert.byrne@Sun.COM>
: To: ietf-ldapext@netscape.com
: Subject: browse permission in the ACM
:
:
: All,
:
: The following is a proposal to tweak the current browse permission in
: the ACM.
: The current usage of the "b" permission in the ACM is really just a read
: level permission on candidate entries. From section 5.2:
:
: " 1. permission "b" to the entry candidateDN
:
: If this permission is not granted then the dn
: candidateDN MUST NOT be returned nor any attribute
: type nor attribute value from this entry.
:
: If this permission is granted then the dn candidateDN
: MAY be returned.
: "
:
: Some people felt that it would be better to have it behave more like
: it's name suggests...which is that you would require this permission to
: be able to have a search request return __non-base__ entries to you
: during a search. The spirit of this idea is something like "Hang on,
: subtree and onelevel searches are really powerful, there should be a
: way continue to grant read access to entries, but to limit the power of
: these search options".
:
: One way to do this is to refine "b" into two permissions 'new "b"' and
: "v".
: The 'new "b"' still stands for browse and you will need this to see
: non-base entries. At a stretch the "v" stands for "vertex" as you need
: this to see the base entry (the vertex) of a search. (From now on "b"
: means 'new "b"'.) To minimize the
: number of combinations we also allow the base element to be seen if "b"
: permission is assigned to it. So, the new text I am proposing for this
: would be:
:
:
: " 1. permission "v" or "b" to the entry candidateDN, if the entry is
: the
: base of the search operation.
: permission "b" to the entry if the entry is not the base of the
: search.
:
: If these conditions are not satisfied then the dn
: candidateDN MUST NOT be returned nor any attribute
: type nor attribute value from this entry.
:
: If this permission is granted then the dn candidateDN
: MAY be returned."
:
: Note that the absence of a "v" or "b" permission at any point does not
: abort the search operation as a whole or even on a particular subtree.
: We could specify such behaviour but I believe most LDAP implementations
: have an "optimistic" approach to searching for entries ie. I may be
: denied access to this entry, but there may be other entries to which I
: do have access, so keep searching.
:
: Note also that if you only ever use "b", it will behave just like a read
: level permission on the entry--we provide the "v" refinement for those
: users that might want to limit "browsability" of their DIT.
:
: An example. Suppose that some given user has all rights on all
: these subtrees, the only difference being in allocation of the "b" and
: "v" rights which are shown in brackets, after the RDN of the entry.
:
: ou=sun.com(b)
: |
: |------------------------------------------------
: | | |
: ou=sortOfBrowsable() ou=notBrowsable(v) ou=Browsable(b)
: | | |
: ou=level1(v) ou=level1(v) ou=level1(b)
: | | |
: ou=level2(b) ou=level2(v) ou=level2(b)
:
:
: Eg 1: If he does a search like this:
:
: baseEntry: ou=sortOfBrowsable,o=sun.com
: filter: ou=*
: scope: subtree
:
: He will get back the following entry:
:
: ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this)
:
: -----
:
: Eg 2: Then, if he does a search like this:
:
: baseEntry: ou=sortOfBrowsable,o=sun.com
: filter: ou=*
: scope: base
:
: He will get back no entries (neither "v" nor "b" on the base).
:
: -----
:
: Eg 3: If he does a search like this:
:
: baseEntry: ou=notBrowsable,ou=sun.com
: filter: ou=*
: scope: subtree
:
: He will get back the following entry:
:
: ou=notBrowsable,ou=sun.com (has "v" and it's the base)
:
: -----
:
:
: Eg 4: If he does a search like this:
:
: baseEntry: ou=notBrowsable,ou=sun.com
: filter: ou=*
: scope: base
:
: He will get back the following entry:
:
: ou=notBrowsable,ou=sun.com (has "v" and it's the base)
:
: -----
:
:
: Eg 5: Then, if he does a search like this:
:
: baseEntry: ou=Browsable,ou=sun.com
: filter: ou=*
: scope: subtree
:
: He will get back the following entries:
: ou=Browsable,ou=sun.com (has "b")
: ou=level1,ou=Browsable,ou=sun.com (has "b")
: ou=level2,ou=Browsable,ou=sun.com (has "b")
:
: -----
:
:
: Eg 6: Then, if he does a search like this:
:
: baseEntry: ou=Browsable,ou=sun.com
: filter: ou=*
: scope: base
:
: He will get back the following entries:
: ou=Browsable,ou=sun.com (has "b")
:
: -----
:
:
: Eg 7: Then, if he does a search like this:
:
: baseEntry: ou=sun.com
: filter: ou=*
: scope: onelevel
:
: He will get back the following entries:
: ou=Browsable,ou=sun.com (has "b")
:
: -----
:
: Any comments on this modification ?
:
: Rob.