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

[Brian Jarvis <bjarvis@internap.com>]

<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: rbyrne@odin.France.Sun.COM [mailto:rbyrne@odin.France.Sun.COM]
Sent: Thursday, December 14, 2000 13:42
To: ietf-ldapext@netscape.com
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.