Re: Why need read privilege on upstream folders to achieve a writ e permission

[James Mason <ma...@apache.org>]

Warwick Burrows wrote:
> Many authorization implementations have the concept of a "traverse"
> permission as I outlined in an earlier email. A permission that allows the
> user to "traverse" into a particular directory but not read the files in
> that directory. They must have traverse permission on the parent directories
> too of course. The read permission in Slide is handling both the traverse
> and read permission cases right now. By adding a "traverse" permission it
> would allow these guys to control who can read the docs in parent
> directories but not stop others from traversing down to directories that
> they can read. 

Just to clarify, your "traverse" permission *is* how the read permission 
works on collections. If you get a list of the children of a collection 
you will only see the children to which you have read access as well. 
Since permissions on collections always inherit you will see all of the 
children in a collection unless you have been specifically denied access.

Try it out, though. Deny yourself access to a file and you won't see it 
in the directory listing.

-James

> 
> Some authorization systems also have a "list" permission which allows the
> user to list the contents of the container/directory. Without the list
> permission they can't check what's in the directory, but if they have a
> direct link to a doc then they can get access to it. This is just to control
> visibility of documents so that those attempting to access docs that they
> shouldn't can't test each doc by listing the dir contents and attempting to
> access each doc that they find.
> 
> Its not a defect that slide operates this way but I agree with James that a
> feature enhancement for this issue would vastly improve the useability of
> Slide's authorization system.
> 
> Warwick 
> 
> 
> -----Original Message-----
> From: James Mason [mailto:masonjm@apache.org] 
> Sent: Monday, August 16, 2004 10:48 AM
> To: Slide Users Mailing List
> Subject: Re: Why need read privilege on upstream folders to achieve a writ e
> permission
> 
> 
> Personally, I don't see this so much as a defect as a feature 
> enhancement. Every other access control system that I'm aware of has a 
> similar constraint; otherwise a user would never be able to navigate to 
> the folder they had access to.
> 
> I think the case for a feature enhancement is strong, though. Several 
> other people have made similar requests and I believe Oliver proposed a 
> solution that would allow inherited acl checking without the user 
> needing read access to parent folders. My only concern with this is that 
> since it differs from the way most security systems work an unaware 
> administrator could accidentally open a security hole without realizing 
> it. If this behavior had to be enabled explicitly, I think that would no 
> longer be a problem.
> 
> As for a timeline, we're in a feature freeze for 2.1 right now, so 
> depending on the magnitude of the change (I haven't looked at what would 
> be involved) it may have to wait until 2.2.
> 
> -James
> 
> Gao Jun wrote:
> 
>>James,
>>
>>I think the root cause of all these problems is Slide requires a user 
>>to have read privileges on all upstream folders to enable himself to 
>>write in a folder he has write privilege on. I think this is not a 
>>reasonable rule and it brings out quite some problems. So I'd like to 
>>know whether you take this as a defect and have a plan to fix it in 
>>the near future?
>> 
>>regards,
>> 
>>Jun
>>
>>James Mason <ma...@apache.org> wrote:
>>Gao Jun wrote:
>>
>>
>>>James,
>>>
>>>Your recommended approach means
>>>
>>>1. each time when I created a new user, I need
>>>to traverse all the nodes in the tree and add "read deny" this new 
>>>user to the node.
>>
>>
>>Not *every* node, since the permissions will inherit, but probably 
>>more
>>nodes than you want to deal with.
>>
>>
>>
>>>2. when I want to assign a folder to this user, I will go to delete 
>>>all the "read deny"s to him in this folder's all upstream folders and 
>>>all downstream folders.
>>
>>
>>Again, inheritance would make this easier.
>>
>>
>>
>>>3. each time I create a new folder, I need to add "read denys" of all 
>>>the users of this system who shouldn't see this folder - I don't know 
>>>how to retrieve this user list yet.
>>
>>
>>You can retrieve the list of users from the /users.
>>
>>
>>
>>>What we are building is a totally dynamic system, users can keep 
>>>creating new users and new folders, each user has his/her own 
>>>accessible folders. Do you think this approach is a feasible one? 
>>>Thanks.
>>
>>
>>Yes, this is feasible. What we've done for our setup is make two
>>"categories" of collections, public and private. Because our default 
>>permissions allow read access to everything for everyone, to make a 
>>section "private" you must explicity deny everyone access. Then you only 
>>grant access to the users/roles that need it for that section. Because 
>>permission inherit you only need to make the root folder a section 
>>private and everything under that folder becomes private as well.
>>
>>For what you're working on it might make sense to enforce some default
>>permissions. You can either do this through your UI or Content 
>>Interceptors/Event Listeners. You should be able to set something up so 
>>that anytime a new collection is created at a certain level it 
>>automatically gets a permission that denys read to everyone and grants 
>>read to the owner/someone else. That will lower your overhead for 
>>creating new folders.
>>
>>-James
>>
>>
>>
>>>regards,
>>>
>>>Jun
>>>
>>>
>>>
>>>
>>>>Ok, I think I understand the issue a bit better now.
>>>>
>>>>What I'd recommend is you start with the largest group of users 
>>>>possible and work your way down. Start by granting read to 
>>>>authenticated on A. This will give all of your users read access to 
>>>>the entire tree, so you don't need to worry about that. For special 
>>>>cases, such as Carl, you'll need to modify the permissions further 
>>>>down. Grant Carl write access to C1 and deny him read access to B2. 
>>>>The consequence of the way inheritance works in Slide is that you're 
>>>>going to have a lot of "deny" permissions to keep people out of 
>>>>certain areas.
>>>>
>>>>-James
>>>
>>>
>>>
>>>---------------------------------
>>>Do you Yahoo!?
>>>New and Improved Yahoo! Mail - Send 10MB messages!
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-user-help@jakarta.apache.org
>>
>>
>>		
>>---------------------------------
>>Do you Yahoo!?
>>Read only the mail you want - Yahoo! Mail SpamGuard.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org