Hello,
It is now clear. Thank you very much for these explanations.
The only one think I still have to understand is why a "grant write on
/a/b/c for toto" is not enought to allow toto to write on /a/b/c, but
this action also requires permissions (I don't know exactly what
permissions) on parent resources. But as you said in one of your last
messages, it could be a client-side problem.
Thomas
delbd wrote:
Le Mardi 28 Juin 2005 09:44, delbd a écrit :
Ok, example, as it seems as thread goes on things get confusing:
let's take the node /a/b/c
The ACL on /a/b/c is build as follow:
ACEs on c
ACEs inheritable from b
ACEs inheritable from a
ACEs inheritable from /
Then to check security, slide takes the requested permission (eg /actions/read)
and the requested user (eg unauthenticated). Slide then follow the ACL build
previously
and read it from top to bottom. The *first* ACE found which match the user and the
requested permission applies (this could be, for example, /actions/read on user all).
If the matching ACE is a grant, then permission is granted. If the matching ACE is a
deny, then permission is denied.
bonus. :-)
How can we know exactly what ACEs to put to grant or deny a permission
(how Slide processes permissions exactly ?)
Just put them in order on /a/b/c, the first to match is applied.
Don't forget when you add permissions to a node already having permissions,
the new permissions you add are put at the top of the list.
Sorry, i mean, they are added at the *bottom* of the list :D
Le Lundi 27 Juin 2005 18:17, Thomas Bellembois a écrit :
Hello Miguel,
I don't understand two thinks :
1.
When you say that "the first inherited is always the last processed", do
you mean that Slide processes inheritable ACE on /b, then inheritable
ACE on /a ... ?
2.
Why ACEs on a resource are not enougth to grant or deny a permission
(cf. my problem on /files/partage/demoEsup) ?
bonus. :-)
How can we know exactly what ACEs to put to grant or deny a permission
(how Slide processes permissions exactly ?)
Thank you.
Thomas
Miguel Figueiredo wrote:
Hello Thomas,
Inherited ACEs are always resolved last. For example, take the following
path:
/slide/file/a/b/c.txt
Slide first checks for c.txt ACEs, then b/ ACEs, then a/ until slide/
collection's ACEs. Means that inherited ACEs are always processed last, and
the first inherited is always the last processed.
Hope this helps,
Miguel Figueiredo
-----Original Message-----
From: Thomas Bellembois [mailto:[EMAIL PROTECTED]
Sent: segunda-feira, 27 de Junho de 2005 15:35
To: Slide Developers Mailing List
Subject: ACL evaluation
Hello,
I have a problem trying to put permission on one resource.
I have understood that ACL's are evaluated from the top to the bottom.
But what about inherited ACL's ? Are they evaluated first ?
I could not find this information neither in the RFC or in the mailing
list. :-(
My problem is that I have the following permissions :
/files/partage : deny all all inheritable
/files/partage/demoEsup : grant read /users/demoEsup inheritable, grant
write /users/demoEsup inheritable
And the user demoEsup can not read or write in the folder
/files/partage/demoEsup.
But if I change the permission on /files/partage into :
/files/partage : deny write all inheritable
it works...
Any idea ?
Thank you very much
Thomas
--
+---=( Thomas Bellembois )=---+
| CRI - University of Rennes 1 - FR |
| [EMAIL PROTECTED] |
| +33 2 23 23 69 60 |
+-----------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
