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]
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]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
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]
Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
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 Like the x flag on unix to allow to change into a directory? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Exactly, and that's a perfect use case as most people are familiar with it. Warwick -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 3:22 PM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working 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 Like the x flag on unix to allow to change into a directory? Oliver - 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]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
One thing I'd like to point out is the read permission in Unix gives the capability to see the contents of the directory. In contrast, read in webdav only gives the capability to see the collection and the properties of the collection... if the permission doesn't inherit. -James On Thu, 2004-10-28 at 13:26 -0700, Warwick Burrows wrote: Exactly, and that's a perfect use case as most people are familiar with it. Warwick -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 3:22 PM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working 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 Like the x flag on unix to allow to change into a directory? Oliver - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
You can't set a permission that is inherited. Inherited means the ACE is really inherited (believe me) from a parent resource. In fact you should filter the ACEs with the inherited flag set before calling the aclMethod(). Luckily the client library does this for you. Ingo Hi, I have been trying for quiet some time to add a permission to a folder using webdav client-lib that does not inherit to the downstream folders. I have taken the code from client-lib that is shipped with slide and am using slide 2.1 B1. In my code I use the following fragment to create an ACE object and bind it to ACL. The code works perfectly if 4th parameter (isInherited) is set to false // Create new ACE object bIsInherited = false aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); The code does not work if 4th parameter (isInherited) is set to true. I am assuming that you set the 4th parameter to true if you are trying to make the permission non-inheritable (not allow it to percolate to the downstream folders). With 4th parameter set to true, webdav client does not throw any error but does not add the permission. Later when I get the ACL for the resource I find that the ace has not been added. Please let me know if I am missing something ... or if it is possible at all to create a permission(ace) in a ACL which does not percolate to downstream folders using webdav client lib. I found that adding a inheritable(false) permission in domain.xml does the job as desired. I am wondering why it is not working from webdav client lib. Any help is appreciated !! /*** code fragment */ // Fetch ACL from slide for a folder AclProperty acl = webDavResource.aclfindMethod(sResourcePath); // Fetch the ACE's (access control entities) of the existing ACL Ace[] aces = acl.getAces(); // Create new ACE object none exists if (aces == null) aces = new Ace[0]; Ace[] oldAces = aces; // Create a new ace array (larger then the earlier ace array by 1) aces = new Ace[oldAces.length + 1]; // Copy the old array into the new array System.arraycopy(oldAces,0,aces,0,oldAces.length); // Create new ACE object bIsInherited = true aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); // Copy the new ace into the new ace array aces[oldAces.length] = aceMatchingPrincipal; // Create a new privilege Privilege privilegeNew = new Privilege(qnPermission.getNamespaceURI(), qnPermission.getLocalName(), null); // Update the ace object with the new privilege settings aceNew.addPrivilege(privilegeNew); // Update repository with new acl for the resource bSuccess = webDavResource.aclMethod(sResourcePath, aces); Krishna (303) 274 3027 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Jason, Do you mean to say that it is not possible to set a permission to a folder that would not inherit to its children. Somehow if I set a permission in Domain.xml with inheritable=false, it does not job (I know it uses slide API directly). This contradicts your statement. Also, I am using webdav client-lib API. Do you think this would be a bug in the webdav client-lib API? Thanks, Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 12:34 AM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working Krishna, As far as I know Slide always sets permissions on collections to inheritable. -James On Mon, 2004-10-25 at 16:49 -0400, Krishna Kankipati wrote: Hi, I have been trying for quiet some time to add a permission to a folder using webdav client-lib that does not inherit to the downstream folders. I have taken the code from client-lib that is shipped with slide and am using slide 2.1 B1. In my code I use the following fragment to create an ACE object and bind it to ACL. The code works perfectly if 4th parameter (isInherited) is set to false // Create new ACE object bIsInherited = false aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); The code does not work if 4th parameter (isInherited) is set to true. I am assuming that you set the 4th parameter to true if you are trying to make the permission non-inheritable (not allow it to percolate to the downstream folders). With 4th parameter set to true, webdav client does not throw any error but does not add the permission. Later when I get the ACL for the resource I find that the ace has not been added. Please let me know if I am missing something ... or if it is possible at all to create a permission(ace) in a ACL which does not percolate to downstream folders using webdav client lib. I found that adding a inheritable(false) permission in domain.xml does the job as desired. I am wondering why it is not working from webdav client lib. Any help is appreciated !! /*** code fragment */ // Fetch ACL from slide for a folder AclProperty acl = webDavResource.aclfindMethod(sResourcePath); // Fetch the ACE's (access control entities) of the existing ACL Ace[] aces = acl.getAces(); // Create new ACE object none exists if (aces == null) aces = new Ace[0]; Ace[] oldAces = aces; // Create a new ace array (larger then the earlier ace array by 1) aces = new Ace[oldAces.length + 1]; // Copy the old array into the new array System.arraycopy(oldAces,0,aces,0,oldAces.length); // Create new ACE object bIsInherited = true aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); // Copy the new ace into the new ace array aces[oldAces.length] = aceMatchingPrincipal; // Create a new privilege Privilege privilegeNew = new Privilege(qnPermission.getNamespaceURI(), qnPermission.getLocalName(), null); // Update the ace object with the new privilege settings aceNew.addPrivilege(privilegeNew); // Update repository with new acl for the resource bSuccess = webDavResource.aclMethod(sResourcePath, aces); Krishna (303) 274 3027 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Michael, I did not get your sentence So this means that you may be unable to preserve the meaning of existing ACEs when adding a new one. Although it is true that you cannot add/remove/modify each ace individually, . adding a new ace will not alter the meaning of existing aces at all. Correct me if I mis-read you statement So, do you mean to say that slide ACL protocol offers no way to set non-inheritable permissions to collections using webdav client lib. What is the meaning of the member variable isInherited in Ace class, if it cannot be set to true. Do you mean to say that it has to be set to false all the time? What is the true meaning of this member variable, it is kind of confusing Krishna -Original Message- From: Michael Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 1:10 AM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working James Mason wrote: Krishna, As far as I know Slide always sets permissions on collections to inheritable. -James Right. The webdav ACL protocol has a strange asymmetry here: it can tell you whether a permission is inheritable or not, but it has no way to specify that (either way) when _setting_ an ACL (whether the ACEs set are inheritable or not is implementation defined). This is particularly troubling since you have to set all the ACEs at once, you can't just add/remove/modify one at a time. So this means that you may be unable to preserve the meaning of existing ACEs when adding a new one. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Ingo, Why is Ace class exposing its isInherited member variable if cannot be set explicitly. It also has a mutator method called setIsInherited(). If value set to false, it works. If set to true it just doesn't do anything (does not throw error too). Seems like a bug. Also, using domain.xml you can create non-inheritable permissions. I have tried that and it works. All I am asking is if I can achieve the same using webdav client lib. Thanks, Krishna -Original Message- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 1:22 AM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working You can't set a permission that is inherited. Inherited means the ACE is really inherited (believe me) from a parent resource. In fact you should filter the ACEs with the inherited flag set before calling the aclMethod(). Luckily the client library does this for you. Ingo Hi, I have been trying for quiet some time to add a permission to a folder using webdav client-lib that does not inherit to the downstream folders. I have taken the code from client-lib that is shipped with slide and am using slide 2.1 B1. In my code I use the following fragment to create an ACE object and bind it to ACL. The code works perfectly if 4th parameter (isInherited) is set to false // Create new ACE object bIsInherited = false aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); The code does not work if 4th parameter (isInherited) is set to true. I am assuming that you set the 4th parameter to true if you are trying to make the permission non-inheritable (not allow it to percolate to the downstream folders). With 4th parameter set to true, webdav client does not throw any error but does not add the permission. Later when I get the ACL for the resource I find that the ace has not been added. Please let me know if I am missing something ... or if it is possible at all to create a permission(ace) in a ACL which does not percolate to downstream folders using webdav client lib. I found that adding a inheritable(false) permission in domain.xml does the job as desired. I am wondering why it is not working from webdav client lib. Any help is appreciated !! /*** code fragment */ // Fetch ACL from slide for a folder AclProperty acl = webDavResource.aclfindMethod(sResourcePath); // Fetch the ACE's (access control entities) of the existing ACL Ace[] aces = acl.getAces(); // Create new ACE object none exists if (aces == null) aces = new Ace[0]; Ace[] oldAces = aces; // Create a new ace array (larger then the earlier ace array by 1) aces = new Ace[oldAces.length + 1]; // Copy the old array into the new array System.arraycopy(oldAces,0,aces,0,oldAces.length); // Create new ACE object bIsInherited = true aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); // Copy the new ace into the new ace array aces[oldAces.length] = aceMatchingPrincipal; // Create a new privilege Privilege privilegeNew = new Privilege(qnPermission.getNamespaceURI(), qnPermission.getLocalName(), null); // Update the ace object with the new privilege settings aceNew.addPrivilege(privilegeNew); // Update repository with new acl for the resource bSuccess = webDavResource.aclMethod(sResourcePath, aces); Krishna (303) 274 3027 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
