Michael,
I completely agree with you.
All,
The reason I think this is very important for a complete ACL based
access system.
I have developed an admin UI for slide repository and the challenge
we are facing is that whenever a principal is assigned a permission
('write','all' etc ...) on a folder, I have to manually assign 'read'
permissions to all the upstream folders (for the user to be able to at least
navigate to that folder).
The problem with this approach is that the entire tree within 'files' folder
gets 'read' assigned to this principal, which breaks the whole purpose of
ACL.
I don't see any other way of getting around this problem than to set all
upstream folders (only those upstream folders user has to navigate to reach
the folder in question) to "non-inheritable read". This way only those
folders which the user has to navigate to reach the folder on which he is
assigned a 'write' is accessible to him (to navigate only). I think if we
cannot to do this it would be a significant drawback to usage of slide
itself as an ACL platform.
I am wondering how the present production systems of slide get around this
problem .... I would like to hear from people who have implemented the
present ACL (vanilla server implementation for ACL) and build navigable
access based repository trees.
Any comments?
Thanks & regards
Krishna
-----Original Message-----
From: Michael Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004 6:06 PM
To: Slide Users Mailing List
Subject: Re: Adding a non-inheritable permission to a folder using webdav
clie nt lib not working
Ingo Brunberg wrote:
> The ACL spec states that you cannot modify an inherited or protected
> ACE.
>
> What about adding a new ACE? I'm not sure. If you add an ACE to a
> collection, isn't it automatically inheritable? Might that depend on a
> particular server implementation? I guess no implementation would
> allow you to add a protected ACE. And maybe the ACL spec should be
> changed to allow marking a new ACE as inheritable.
>
> Reagrds,
> Ingo
When setting an ACL (note that any modification to an ACL requires you
to set the _entire_ ACL: there's no way to just add/remove/modify a
single ACE), the inheritability of ACEs in the request is implementation
defined - anything could happen.
Slide interprets it as always being inheritable (this is the best option
available in the current spec, since there's no way for the client to
specify desired inheritability).
I'd support changing the spec to allow setting inheritability on ACEs
explicitly. I'm not sure what problems this might have for other
implementations, though - I suspect slide is unusual in being able to
set this seperately per-ACE.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
