[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: browse permission in the ACM

To: ietf-ldapext@netscape.com, robert.byrne@Sun.COM
Subject: Re: browse permission in the ACM
From: rvh@qsun.mt.att.com (Richard V Huber)
Date: Thu, 19 Apr 2001 16:07:32 -0400
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?

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.

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.
: 
: 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.
Follow-Ups:
- Re: browse permission in the ACM
  - From: robert byrne <robert.byrne@Sun.COM>
Prev by Date: Are You Being Investigated? -swqmhy
Next by Date: Re: browse permission in the ACM
Index(es):
- Chronological
- Thread