The structure of the repository I run is largely public with a fair
number of private sections. The admin UI I wrote allows the manager of
each section to override the inherited permissions if they want to make
their section private.
The biggest issue we've run into so far is when someone wants a publicly
accessible sections inside of a private section. I've heard that
providing a direct link to the public section works, but I haven't
tested it.
-James
On Thu, 2004-10-28 at 11:57 -0400, Krishna Kankipati wrote:
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
