Re: browse permission in the ACM

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

All,

By way of a partial conclusion of this thread, for the next draft I
intend to propose 3. below.

Rob.

robert byrne wrote:
> 
> Rick,
> 
> Maybe now is a good time to list the options (that I can think of) open
> to us for this browsing concept:
> 
> 1. Keep it as is in section 5.2, so that "b" is just an entry-level
> permission you need on all entries when you search.
> 
> 2. Drop it entirely, so that we have no dedicated entry-level permission
> on search.  For example, we don't have an entry-level Modify
> permission.  In this model, we would be relying on the returnDn
> permission for entry-level protection.  I guess "entry-level protection"
> of an entry in the context of search means protecting the dn so this
> seems to make sense.
> 
> 3. Keep "b" but only require it on non-base entries.  This means that
> you can control the power of the subtree and onelevel search options on
> your DIT.
> 
> 4. Keep "b" but only require it on non-base entries AND introduce a "v"
> which you are now required to see base entries of searches.  This means
> that you can control the power of the subtree and onelevel search
> options on your DIT AND allows you to explicitly protect bases of
> searches at the entry level.
> 
> 5. As 4. but have "b"=>"v", so that if you want you can forget about "v"
> and just use "b" as in 1.  This is what I proposed in my earlier mail.
> 
> I agree that it is not worth complicating things for this browsing
> capability.  Given this, if people like the ability to put a brake on
> the subtree and onelevel options (I guess the use of these options is
> what we mean by "browsing" in LDAP), I'm tempted to propose 3. as the
> simplest option.  After that if we consider that controling browsing is
> not important, I'm tempted by 2., namely dropping "b" entirely...though
> we'd need to check that this doesn't leave some holes.
> 
> Any votes/opinions on these options ?
> 
> Rick, for your other point on aborting searches re the returnDn
> permission, I would prefer to discuss that in a different thread called
> something like "protecting dns in the ACM", as I think it desreves a
> discussion itself.
> 
> Rob.
> 
> Richard V Huber wrote:
> >
> > 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.