[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: Fri, 20 Apr 2001 10:59:58 +0200
Cc: ietf-ldapext@netscape.com
Organization: Sun Microsystems
References: <200104192007.QAA24666@qsun.mt.att.com>
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.
> :
> : 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.
References:
- Re: browse permission in the ACM
  - From: rvh@qsun.mt.att.com (Richard V Huber)
Prev by Date: Re: browse permission in the ACM
Next by Date: piece wise retrieval of multivalued attrib.
Index(es):
- Chronological
- Thread