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. 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 > > > > > > > > -- David Delbecq Royal Meteorological Institute of Belgium - Is there life after /sbin/halt -p? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
