All,
I think it would be an extremely important feature to have (rather
it's a handicap not to have that feature), how do you go about proposing to
the DAV acl spec group, I have never done that?
Krishna
-----Original Message-----
From: Warwick Burrows [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 28, 2004 10:20 AM
To: 'Slide Users Mailing List'
Subject: RE: Adding a non-inheritable permission to a folder using webdav
clie nt lib not working
Guys,
There was another email thread like this recently regarding a users need to
have the read bit on a folder to navigate through it to get to children. I
worked on an authorization product at one time and our solution was to
define another permission called "traverse" that would permit a user to
traverse through a collection but not be able to list or read the contents
of that collection. Incidentally, we also defined a "list" permission that a
user would need to actually list the contents of a particular collection -
though this was mainly for GUI purposes when traversing a visual tree by
clicking. I was surprised that the DAV acl spec doesn't define a traverse
permission as it is exactly what's needed to permit a user to traverse to a
certain point in the tree without being able to see any of the files in the
collections upstream.
Anyway, I realize that this doesn't help to solve your problem right now,
but my question is whether its the right answer for the DAV acl spec in
general. Would it be worth proposing this to the DAV acl spec group so that
we can make DAV access control more flexible and more useful in the future?
Warwick
> -----Original Message-----
> From: Krishna Kankipati [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 28, 2004 10:58 AM
> To: 'Slide Users Mailing List'; '[EMAIL PROTECTED]'
> Cc: Martin Olovsson; Jagadeesh Sunkara
> Subject: RE: Adding a non-inheritable permission to a folder
> using webdav clie nt lib not working
>
>
> 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]
