rapport.pdf @@ -82,7 +82,44 @@ Dans une modèle de de sécurise ACL, si quelque agent faire une requête pour a Le format des règles sont formée par une indicateur de classe (comme les classe du système Traditionnel), une quantificateur pour spécifier de quel utilisateur ou group on parle et les octet de permission. - + +Avec cette représentation le sens de la classe du groupe a redéfini comment le limite supérieur de les permission de chaque entrée dans la classe du groupe. Ça arrive parce que les entrée du groupe et du utilisateur nommées seront désigner à entrée du groupe \footnote{Fabricio: Je ne comprend pas cette affirmation, je laisse ici le teste orignial: +These named group and named user entries are assigned to the group class, which already contains the owning group entry. Different from the POSIX.1 permission model, the group class may now contain ACL entries with different permission sets, so the group class permissions alone are no longer sufficient to represent all the detailed permissions of all ACL entries it contains. Therefore, the meaning of the group class permissions is redefined: under their new semantics, they represent an upper bound of the permissions that any entry in the group class will grant.}. + +% +% This upper bound property ensures that POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported. +% +% In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions. +% +% This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant. Figure 1 shows these two cases. +% +% Figure: Mapping between ACL Entries and File Mode Permission Bits \begin{figure}\begin{centering} \par \epsfig{file=acl_mapping_minimal.eps, scale... ...sfig{file=acl_mapping_extended.eps, scale=0.7} \par\end{centering}\end{figure} +% +% When an application changes any of the owner, group, or other class permissions (e.g., via the chmod command), the corresponding ACL entry changes as well. Likewise, when an application changes the permissions of an ACL entry that maps to one of the user classes, the permissions of the class change. +% +% The group class permissions represent the upper bound of the permissions granted by any entry in the group class. With minimal ACLs this is trivially the case. With extended ACLs, this is implemented by masking permissions (hence the name of the mask entry): permissions in entries that are a member of the group class which are also present in the mask entry are effective. Permissions that are absent in the mask entry are masked and thus do not take effect. See Table 2. +% +% +% Table: Masking of Permissions +% Entry type Text form Permissions +% Named user user:joe:r-x r-x +% Mask mask::rw- rw- +% Effective permissions r- +% +% +% The owner and other entries are not in the group class. Their permissions are always effective and never masked. +% +% +% +% So far we have only looked at ACLs that define the current access permissions of file system objects. This type is called access ACL. A second type called default ACL is also defined. They define the permissions a file system object inherits from its parent directory at the time of its creation. Only directories can be associated with default ACLs. Default ACLs for non-directories would be of no use, because no other file system objects can be created inside non-directories. Default ACLs play no direct role in access checks. +% +% When a directory is created inside a directory that has a default ACL, the new directory inherits the parent directory's default ACL both as its access ACL and default ACL. Objects that are not directories inherit the default ACL of the parent directory as their access ACL only. +% +% The permissions of inherited access ACLs are further modified by the mode parameter that each system call creating file system objects has. The mode parameter contains nine permission bits that stand for the permissions of the owner, group, and other class permissions. The effective permissions of each class are set to the intersection of the permissions defined for this class in the ACL and specified in the mode parameter. +% +% If the parent directory has no default ACL, the permissions of the new file are determined as defined in POSIX.1. The effective permissions are set to the permissions defined in the mode parameter, minus the permissions set in the current umask. +% +% The umask has no effect if a default ACL exists. rapport.tex 9e1a11eaef1efe24b7d723c7da4ab3fa071f8e92 Fabricio Nascimento fabriciosn@gmail.com http://github.com/Fabs/Acl-Work/commit/2f8a7d1243305f5d5f79bb31329171508166439d 2f8a7d1243305f5d5f79bb31329171508166439d 2009-11-08T05:35:46-08:00 2009-11-08T05:35:46-08:00 Footnote of the not comprensible text 85d03d42738c3949d84f311b5fe796e6dd1d57e2 Fabricio Nascimento fabriciosn@gmail.com