Subject: ldap acl draft(06): browse permission needed ?

From: [email-masked] (Rob Byrne - Sun Microsystems)
Date: Thu, 14 Dec 2000 12:41:47 -0800

In the current acl draft (06) there is a browse permssion proposed and in the discussion at Pittsburgh
people seemed to like it. 
To recap, this permssion is revelvant to the search operation only and the idea is to be able to define a policy whereby you are
only returned entries that you explicitly name.  So, to give a specific example, in a tree with a flat name space, where the entries 
did not have this permission then you could do base searches at individual entries but if you went up a level and
did a subtree search, you would see nothing.  So you can see this permssion as a way to still allow limited access but to kind of put a break on the 
search operation.

I have some proposals for working this into the current draft but it is trickier than just having a simple
"read" permssion on all entries.  In fact I think that when you start to use a browse permssion you also need another to protect the
base of the search too.

It's all doable but don't forget the search already has to deal with filter permssions, attribute level permssion,
returnDN (for aliases) and the infamous discloseOnError permission.  You've probably guessed my inclination is to just define one "read" 
permssion at the entry level--the reasons are ease of definition and ease of administration.  My question is do people still feel the
extra granularity of the browse permssion is needed and if so, please provide a compelling deployment scenario.

If people don't come back and say "We really need this" then my plan is to drop it for the 07 draft...if they do then I'll work
in a proposal, using your scenario as a motivating example (so you will be on the hook too!)

Rob.

---

From: Brian Jarvis <[email-masked]>
Date: Wed, 20 Dec 2000 14:30:10 -0700

I'm making this reply mostly as documentation of our discussion Friday
morning in San Diego.

I believe the intent of the browseDN was to prevent discovery of DNs.  As
long as the effects of readEntry are documented on each operation (it MUST
be checked on search but MUST NOT be checked during bind, etc.), I believe
it can meet that intent.  If it is easier to document, explain, or
implement, it might be better than browseDN.

--the walrus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 14, 2000 13:42
To: [email-masked]
Subject: ldap acl draft(06): browse permission needed ?

In the current acl draft (06) there is a browse permssion proposed and in
the discussion at Pittsburgh
people seemed to like it. 
To recap, this permssion is revelvant to the search operation only and the
idea is to be able to define a policy whereby you are
only returned entries that you explicitly name.  So, to give a specific
example, in a tree with a flat name space, where the entries 
did not have this permission then you could do base searches at individual
entries but if you went up a level and
did a subtree search, you would see nothing.  So you can see this permssion
as a way to still allow limited access but to kind of put a break on the 
search operation.

I have some proposals for working this into the current draft but it is
trickier than just having a simple
"read" permssion on all entries.  In fact I think that when you start to use
a browse permssion you also need another to protect the
base of the search too.

It's all doable but don't forget the search already has to deal with filter
permssions, attribute level permssion,
returnDN (for aliases) and the infamous discloseOnError permission.  You've
probably guessed my inclination is to just define one "read" 
permssion at the entry level--the reasons are ease of definition and ease of
administration.  My question is do people still feel the
extra granularity of the browse permssion is needed and if so, please
provide a compelling deployment scenario.

If people don't come back and say "We really need this" then my plan is to
drop it for the 07 draft...if they do then I'll work
in a proposal, using your scenario as a motivating example (so you will be
on the hook too!)

Rob.

---

From: Brian Jarvis <[email-masked]>
Date: Wed, 20 Dec 2000 14:40:37 -0700

<devil's advocate mode on>

1.  If there is a readEntry permission, shouldn't there be a writeEntry?

Just as readEntry would shut off all means of seeing an entry, independent
of any attribute level permissions, writeEntry could prevent all
modifications, despite any attribute level permissions.  It might not grant
any permissions by itself, but it is a prerequisite for other permissions.

2.  I am assuming that readEntry would be checked before readAttribute.
Would it also be checked before writeAttribute?  If not, then can I tell
that an object exists by attempting a modify and looking at the error code?

--the walrus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 14, 2000 13:42
To: [email-masked]
Subject: ldap acl draft(06): browse permission needed ?

Rob.