Question Introduction aux ACL (suite)

On l'a vu dans la première partie sur les ACL (Access Control List), l'objet retourné par get-acl contient une propriété Access qui elle-même contient toutes les ACE (Access Control Entry) qui nous intéressent pour comprendre quelles permissions s'appliquent à un objet donné (le plus souvent un fichier ou un répertoire, mais ça peut également être une entrée de registre).

Les ACE appliquées aux fichiers et répertoires sont des objets de type Security.AccessControl.FileSystemAccessRule . D'autres types existent qui correspondent aux autres objets sur lesquels des ACL (et donc des ACE) peuvent s'appliquer. Tous ces types sont en fait des déclinaisons d'une même classe de base : AccessRule .

La connaissance du type FileSystemAccessRule est importante pour passer à la vitesse supérieure, à savoir modifier les ACL.

Regardons la commande set-acl : dans sa forme la plus simple, elle prend en paramètres un chemin (-path) et un objet ACL (-AclObject). On peut facilement fournir le premier, le deuxième est plus difficile à obtenir. C'est cela qu'on va voir maintenant.

Méthode 1 : copie d'une ACL existante

Dans la mesure où get-acl et set-acl manipulent le même type d'objet, on peut passer à set-acl un objet obtenu grâce à get-acl.

C'est intéressant si, par exemple, on a créé un dossier modèle avec les permissions adéquates, qu'on peut appliquer à d'autres répertoires :

[code:1]
PS> $acl = get-acl h:\template
PS> set-acl h:\partages\vrac $acl
[/code:1]

Ici, on a appliqué à h:/partages/vrac les permissions en place sur h:/template.

Cette méthode a évidemment de grosses limites. Bien souvent les permissions souhaitées sont propres au répertoire considéré : dans le cas d'un répertoire privé, on voudra préciser le nom de l'utilisateur propriétaire, ou dans le cas d'un répertoire partagé, on voudra préciser les noms de groupes spécifiques aux accès en lecture et en écriture sur ce répertoire. C'est là qu'une autre méthode est nécessaire.

Méthode 2 : modification d'une ACL existante

Si on regarde de plus près l'objet $acl retourné par get-acl, on constate qu'il a des méthodes intéressantes, notamment :

[code:1]
PS C:\test> $acl | get-member -member method *accessrule


TypeName: System.Security.AccessControl.DirectorySecurity

Name MemberType Definition
----

---

---

AddAccessRule Method System.Void AddAccessRule(System.Security.AccessControl.FileSystemAccessRule rule)
ModifyAccessRule Method bool ModifyAccessRule(System.Security.AccessControl.AccessControlModification modificati...
RemoveAccessRule Method bool RemoveAccessRule(System.Security.AccessControl.FileSystemAccessRule rule)
ResetAccessRule Method System.Void ResetAccessRule(System.Security.AccessControl.FileSystemAccessRule rule)
SetAccessRule Method System.Void SetAccessRule(System.Security.AccessControl.FileSystemAccessRule rule)
[/code:1]

J'ai testé pour vous les méthodes AddAccessRule et RemoveAccessRule.

Même si les autres sont évidemment très utiles également, ces deux méthodes de base permettent de faire l'essentiel des modifications dont on aura besoin.

Avant tout, on notera que l'argument à passer à chacune de ces méthodes est un objet de type System.Security.AccessControl.FileSystemAccessRule. Ca vous dit quelque chose ? Oui, c'est le type de chacun des éléments de la propriété Access de $acl, les fameuses ACE.

Si on regarde le lien MSDN fourni plus haut pour ce type, on peut voir une section \"Constructeur\" : les constructeurs sont les différentes syntaxes possibles pour créer un objet de ce type. Dans PowerShell, on utilisera ces syntaxes pour déterminer les arguments à ajouter à la commande new-object.

Voyons un cas avec le constructeur le plus simple, le 2e dans la liste des constructeurs affichés pour le type FileSystemAccessRule. Ce constructeur prend trois arguments : le nom d'un compte utilisateur, une valeur qui représente une permission, et une valeur indiquant si la permission doit être autorisée (\"Allow\") ou interdite (\"Deny\").

Imaginons qu'on veuille autoriser un utilisateur (par exemple l'utilisateur mpokora du domaine EUROPE) à modifier le contenu du répertoire privé qu'on lui a créé sur h:/users/mpokora. On commencera donc par créer un objet ACE avec les trois arguments vus ci-dessus, et on ajoutera cette ACE à l'ACL du répertoire. Voyons tout ça :

[code:1]
PS> $acl = get-acl h:\users\mpokora
PS> $ace = new-object Security.AccessControl.FileSystemAccessRule(\"EUROPE\mpokora\", \"Modify\", \"Allow\"«»)
PS> $acl.AddAccessRule($ace)
PS> set-acl h:\users\mpokora $acl
[/code:1]

Quoi, c'est tout ? Hé oui !

Avant de vous laisser digérer tout ça, je vais juste vous indiquer comment récupérer les différentes valeurs utilisables pour indiquer les permissions requises :

[code:1]
PS> [Enum]::GetNames([Security.AccessControl.FileSystemRights])
ListDirectory
ReadData
WriteData
CreateFiles
CreateDirectories
AppendData
ReadExtendedAttributes
WriteExtendedAttributes
Traverse
ExecuteFile
DeleteSubdirectoriesAndFiles
ReadAttributes
WriteAttributes
Write
Delete
ReadPermissions
Read
ReadAndExecute
Modify
ChangePermissions
TakeOwnership
Synchronize
FullControl
[/code:1]

A suivre (pas aujourd'hui), plus de détails sur les permissions et sur les notions d'héritage.

Bonne digestion. <br><br>Message édité par: janel, à: 27/01/11 14:30