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

To: Richard V Huber <rvh@qsun.mt.att.com>
Subject: Re: browse permission in the ACM
From: robert byrne <robert.byrne@Sun.COM>
Date: Wed, 11 Apr 2001 12:26:43 +0200
Cc: ietf-ldapext@netscape.com
Organization: Sun Microsystems
References: <200104101510.LAA24387@qsun.mt.att.com>
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>
References:
- Re: browse permission in the ACM
  - From: rvh@qsun.mt.att.com (Richard V Huber)
Prev by Date: RE: IP Address in the ACM (Was: Comments onAccessControlModel- BNF)
Next by Date: protecting dns in the ACM
Index(es):
- Chronological
- Thread