Comprendre les bits en mode dans Azure NetApp Files
Les autorisations d’accès aux fichiers dans NFS limitent ce que les utilisateurs et les groupes peuvent faire une fois qu’un volume NAS est monté. Les bits de mode sont une fonctionnalité clé des autorisations de fichier NFS dans Azure NetApp Files.
Bits du mode NFS
Les autorisations de bits en mode dans NFS fournissent des autorisations de base pour les fichiers et les dossiers, à l’aide d’une représentation numérique standard des contrôles d’accès. Les bits de mode peuvent être utilisés avec NFSv3 ou NFSv4.1, mais les bits de mode sont l’option standard pour sécuriser NFSv3 comme défini dans RFC-1813. Le tableau suivant montre comment ces valeurs numériques correspondent aux contrôles d’accès.
| Numérique du bit en mode |
|---|
| 1 – exécuter (x) |
| 2 – écriture (w) |
| 3 – écriture/exécution (wx) |
| 4 – lecture (r) |
| 5 – lecture/exécution (rx) |
| 6 – lecture/écriture (rw) |
| 7 – lecture/écriture/exécution (rwx) |
Les valeurs numériques sont appliquées à différents segments d’un contrôle d’accès : propriétaire, groupe et tout le monde, ce qui signifie qu’il n’existe aucun contrôle d’accès utilisateur granulaire en place pour NFSv3 de base. L’image suivante montre un exemple de construction d’un contrôle d’accès au bit en mode pour une utilisation avec un objet NFSv3.
Azure NetApp Files ne prend pas en charge les ACL POSIX. Par conséquent, les ACL granulaires sont possibles uniquement avec NFSv3 lors de l’utilisation d’un volume de style de sécurité NTFS avec des mappages de noms UNIX valides pour Windows via un service de noms tel qu’Active Directory LDAP. Vous pouvez également utiliser NFSv4.1 avec Azure NetApp Files et NFSv4.1 ACL.
Le tableau suivant compare la granularité d’autorisation entre les bits en mode NFSv3 et les ACL NFSv4.x.
| Bits en mode NFSv3 | Listes de contrôle d’accès NFSv4.x |
|---|---|
|
|
Pour plus d’informations, consultez Comprendre les listes de contrôle d’accès NFSv4.x.
Bits collants, setuid et setgid
Lorsque vous utilisez des bits en mode avec des montages NFS, la propriété des fichiers et dossiers est basée sur l’utilisateur uid gid qui a créé les fichiers et dossiers. En outre, lorsqu’un processus s’exécute, il s’exécute en tant qu’utilisateur qui l’a lancé et aurait donc les autorisations correspondantes. Avec des autorisations spéciales (telles que setuid, , setgidbit collant), ce comportement peut être contrôlé.
Setuid
Le setuid bit est désigné par un « s » dans la partie d’exécution du bit propriétaire d’une autorisation. Le setuid bit permet à un fichier exécutable d’être exécuté en tant que propriétaire du fichier plutôt que comme utilisateur qui tente d’exécuter le fichier. Par exemple, l’application /bin/passwd a le setuid bit activé par défaut. Par conséquent, l’application s’exécute en tant que racine lorsqu’un utilisateur tente de modifier son mot de passe.
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
Si le setuid bit est supprimé, la fonctionnalité de modification de mot de passe ne fonctionne pas correctement.
# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
passwd: password unchanged
Lorsque le setuid bit est restauré, l’application passwd s’exécute en tant que propriétaire (racine) et fonctionne correctement, mais uniquement pour l’utilisateur exécutant la commande passwd.
# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Setuid n’a aucun effet sur les répertoires.
Setgid
Le setgid bit peut être utilisé sur les fichiers et les répertoires.
Avec les répertoires, setgid peut être utilisé comme moyen d’hériter du groupe propriétaire pour les fichiers et dossiers créés sous le répertoire parent avec le jeu de bits. Comme setuid, le bit exécutable est remplacé par un « s » ou un « S ».
Remarque
Le « S » majuscule signifie que le bit exécutable n’a pas été défini, par exemple si les autorisations sur le répertoire sont « 6 » ou « rw ».
Par exemple :
# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw- 2 user1 group1 4096 Oct 11 16:34 testdir
# who
root ttyS0 2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root root 4096 Oct 11 16:37 ..
-rw-r--r-- 1 root group1 0 Oct 11 17:09 file
Pour les fichiers, setgid se comporte de la même façon que les exécutables s’exécutent à setuidl’aide des autorisations de groupe du propriétaire du groupe. Si un utilisateur se trouve dans le groupe propriétaire, cet utilisateur a accès à l’exécution de l’exécutable lorsque setgid est défini. S’ils ne sont pas dans le groupe, ils n’ont pas accès. Par exemple, si un administrateur souhaite limiter les utilisateurs pouvant exécuter la mkdir commande sur un client, ils peuvent utiliser setgid.
Normalement, /bin/mkdir dispose de 755 autorisations avec propriété racine. Cela signifie que tout le monde peut s’exécuter mkdir sur un client.
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
Pour modifier le comportement afin de limiter les utilisateurs pouvant exécuter la mkdir commande, modifiez le groupe propriétaire de l’application mkdir , modifiez les autorisations pour /bin/mkdir 750, puis ajoutez le bit setgid à mkdir.
# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep 5 2019 /bin/mkdir
Par conséquent, l’application s’exécute avec des autorisations pour group1. Si l’utilisateur n’est pas membre group1, l’utilisateur n’a pas accès à l’exécution mkdir.
User1 est membre de group1, mais user2 n’est pas :
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
Après cette modification, user1 peut s’exécuter mkdir, mais user2 ne peut pas depuis user2 n’est pas dans group1.
# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x 2 user1 group1 4096 Oct 11 18:48 test
# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied
Sticky bit
Le bit sticky est utilisé uniquement pour les répertoires et, lorsqu’il est utilisé, contrôle les fichiers qui peuvent être modifiés dans ce répertoire, quelles que soient leurs autorisations de bits en mode. Lorsqu’un bit sticky est défini, seuls les propriétaires de fichiers (et la racine) peuvent modifier des fichiers, même si les autorisations de fichier sont affichées comme « 777 ».
Dans l’exemple suivant, le répertoire « sticky » se trouve dans un volume Azure NetApp Fils et dispose d’autorisations ouvertes larges, mais le bit sticky est défini.
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
Dans le dossier, les fichiers appartiennent à différents utilisateurs. Tous disposent de 777 autorisations.
# ls -la
total 8
drwxrwxrwt 2 root root 4096 Oct 11 19:29 .
drwxrwxrwx 8 root root 4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2 group1 0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1 40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1 group1 33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2 group1 34 Oct 11 19:27 user2-file
Normalement, toute personne peut modifier ou supprimer ces fichiers. Toutefois, étant donné que le dossier parent a un bit fixe, seuls les propriétaires de fichiers peuvent apporter des modifications aux fichiers.
Par exemple, user1 ne peut pas modifier ni supprimer user2-file:
# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file
rm: can't remove 'user2-file': Operation not permitted
À l’inverse, user2 ne peut pas modifier ni supprimer user1-file , car ils ne possèdent pas le fichier et que le bit sticky est défini sur le répertoire parent.
# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file
rm: can't remove 'user1-file': Operation not permitted
Toutefois, la racine peut toujours supprimer les fichiers.
# rm UNIX-file
Pour modifier la capacité de la racine à modifier des fichiers, vous devez squashing racine à un autre utilisateur à l’aide d’une règle de stratégie d’exportation Azure NetApp Files. Pour plus d’informations, consultez la squashing racine.
Umask
Dans les opérations NFS, les autorisations peuvent être contrôlées via des bits en mode, qui tirent parti des attributs numériques pour déterminer l’accès aux fichiers et aux dossiers. Ces bits de mode déterminent les attributs de lecture, d’écriture, d’exécution et spéciaux. Numériquement, les autorisations sont représentées comme suit :
- Exécuter = 1
- Lecture = 2
- Écriture = 4
Les autorisations totales sont déterminées par l’ajout ou la soustraction d’une combinaison du précédent. Par exemple :
- 4 + 2 + 1 = 7 (peut tout faire)
- 4 + 2 = 6 (lecture/écriture)
Pour plus d’informations, consultez l’aide sur les autorisations UNIX.
Umask est une fonctionnalité qui permet à un administrateur de restreindre le niveau d’autorisations autorisé à un client. Par défaut, l’umask pour la plupart des clients a la valeur 0022. 0022 signifie que les fichiers créés à partir de ce client sont affectés à ce umask. L’umask est soustrait des autorisations de base de l’objet. Si un volume a 0777 autorisations et est monté à l’aide de NFS sur un client avec un umask de 0022, les objets écrits à partir du client dans ce volume ont un accès 0755 (0777 – 0022).
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
Toutefois, de nombreux systèmes d’exploitation n’autorisent pas la création de fichiers avec des autorisations d’exécution, mais ils permettent aux dossiers d’avoir les autorisations appropriées. Ainsi, les fichiers créés avec un umask de 0022 peuvent se retrouver avec des autorisations de 0644. L’exemple suivant utilise RHEL 6.5 :
# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x. 2 root root 4096 Apr 23 14:39 umask_dir
# touch umask_file
# ls -la | grep umask_file
-rw-r--r--. 1 root root 0 Apr 23 14:39 umask_file
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour