You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Daniel Ellermann <da...@amc-world.de> on 2001/10/03 11:17:30 UTC
Deny permissions
Hello,
if I have a tree like this and node A has the inheritable permission
/actions/view.
|
+-+ A /actions/view
| |
| +-+ B /actions/view (inherited)
| | |
| | +-+ C /actions/view (inherited)
| | | |
| | | +- D /actions/view (inherited)
Now I want to revoke this permission at B and C, but leave it at D.
|
+-+ A /actions/view
| |
| +-+ B
| | |
| | +-+ C
| | | |
| | | +- D /actions/view
At node B, I cannot revoke this permission, because it is inherited from A.
If I deny it, I will also deny the permissions for C and D respectively. I
don't want to revoke this permission at A, because new nodes inserted below
A wouldn't have this permission, which is not wishful. Is it intentional
that deny influences all nodes below?
Thank you for your help.
Danny =:-)
AW: Deny permissions
Posted by Daniel Ellermann <da...@amc-world.de>.
I forgot to say that the stated tree is a user tree. If you have a
particular object X, how can I set the following permissions for users A to
D on object X?
|
+-+ A /actions/view
| |
| +-+ B
| | |
| | +-+ C
| | | |
| | | +- D /actions/view
If I deny the permission on X for user B, it is denied for C and D as well.
I cannot grant permission on X for user D in this case. Is it intentional?
Thank you
Danny =:-)
-----Ursprungliche Nachricht-----
Von: Dirk Verbeeck [mailto:dirk.verbeeck@pandora.be]
Gesendet: Mittwoch, 3. Oktober 2001 22:44
An: slide-user@jakarta.apache.org
Betreff: Re: Deny permissions
This is something that is missing from the acl webdav spec, control over
the inheritance of your permission. There is something in the advanced
acl spec but it's in a very early stage.
Slide itself has non-inhetited permissions, using the domain.xml you
could do what you want, or write a webapp.
For your problem, you could always
A : grant
B : deny
C : (deny inherited)
D : grant
But I agree, some control over the inheritance would be easy.
Dirk
Daniel Ellermann wrote:
>
> Hello,
>
> if I have a tree like this and node A has the inheritable permission
> /actions/view.
>
> |
> +-+ A /actions/view
> | |
> | +-+ B /actions/view (inherited)
> | | |
> | | +-+ C /actions/view (inherited)
> | | | |
> | | | +- D /actions/view (inherited)
>
> Now I want to revoke this permission at B and C, but leave it at D.
>
> |
> +-+ A /actions/view
> | |
> | +-+ B
> | | |
> | | +-+ C
> | | | |
> | | | +- D /actions/view
>
> At node B, I cannot revoke this permission, because it is inherited from
A.
> If I deny it, I will also deny the permissions for C and D respectively. I
> don't want to revoke this permission at A, because new nodes inserted
below
> A wouldn't have this permission, which is not wishful. Is it intentional
> that deny influences all nodes below?
>
> Thank you for your help.
>
> Danny =:-)
Re: Deny permissions
Posted by Dirk Verbeeck <di...@pandora.be>.
This is something that is missing from the acl webdav spec, control over
the inheritance of your permission. There is something in the advanced
acl spec but it's in a very early stage.
Slide itself has non-inhetited permissions, using the domain.xml you
could do what you want, or write a webapp.
For your problem, you could always
A : grant
B : deny
C : (deny inherited)
D : grant
But I agree, some control over the inheritance would be easy.
Dirk
Daniel Ellermann wrote:
>
> Hello,
>
> if I have a tree like this and node A has the inheritable permission
> /actions/view.
>
> |
> +-+ A /actions/view
> | |
> | +-+ B /actions/view (inherited)
> | | |
> | | +-+ C /actions/view (inherited)
> | | | |
> | | | +- D /actions/view (inherited)
>
> Now I want to revoke this permission at B and C, but leave it at D.
>
> |
> +-+ A /actions/view
> | |
> | +-+ B
> | | |
> | | +-+ C
> | | | |
> | | | +- D /actions/view
>
> At node B, I cannot revoke this permission, because it is inherited from A.
> If I deny it, I will also deny the permissions for C and D respectively. I
> don't want to revoke this permission at A, because new nodes inserted below
> A wouldn't have this permission, which is not wishful. Is it intentional
> that deny influences all nodes below?
>
> Thank you for your help.
>
> Danny =:-)