Priorité de l'utilisateur et du propriétaire du groupe dans les autorisations de fichier

20

Je viens de rencontrer quelque chose d'inattendu (pour moi) concernant les autorisations de fichiers sur Linux (Arch Linux). Fondamentalement, j'ai:

  • userX dans groupX
  • fileX userX:groupX ---rwx----

Ce qui me laisse perplexe: je ne peux effectuer aucune action ( rwx) sur fileX. Est-ce correct? Quelqu'un peut-il confirmer qu'il s'agit bien du comportement attendu?

Les seules actions que je peux effectuer sont mvet rmparce que j'ai des autorisations d'écriture sur le répertoire parent.

Le truc, c'est que j'ai toujours pensé que ces autorisations s'effondraient les unes sur les autres, à commencer par la plus générale (autre -> groupe -> utilisateur). En d'autres termes, si o=rwxqui s'en soucie quelles sont les persmissions pour le groupe et l'utilisateur? Apparemment, ce n'est pas le cas, mais cela n'a pas beaucoup de sens pour moi; cela semble contre-intuitif. La seule chose à laquelle cette approche semble être utile, c'est d'exclure facilement une personne / un groupe très spécifique, ce qui ne semble pas être une façon intelligente de s'y attaquer (à mon humble avis). D'ailleurs, le propriétaire (et le groupe?) Devrait pouvoir de chmodtoute façon non? Des réflexions à ce sujet?

alex
la source
êtes-vous définitivement dans groupX?
exussum
oui, certainement; vérifié effectif gid avecid
alex

Réponses:

24

Le truc, c'est que j'ai toujours pensé que ces autorisations s'effondraient les unes sur les autres, à commencer par la plus générale (autre -> groupe -> utilisateur).

Si c'était le cas, les «autres» autorisations s'appliqueraient à tout le monde.

En d'autres termes, si o = rwx, peu importe quelles sont les persmissions pour le groupe et l'utilisateur?

C'est différent de votre phrase précédente. Ici, vous sous-entendez que les autorisations sont combinées, par exemple, que userX a la permission de lecture si userX possède le fichier et que le fichier est lisible par l'utilisateur, ou si un groupe auquel appartient userX possède le fichier et le fichier est groupe -readable, ou si le fichier est lisible par un autre. Mais ce n'est pas comme ça que ça fonctionne. En fait, cela o=rwxsignifie que les rwxautorisations s'appliquent aux autres, mais cela ne dit rien sur les entités qui ne sont pas des autres.

Tout d'abord, peu importe à quels groupes un utilisateur appartient. Le noyau n'a pas la notion d'utilisateurs appartenant à des groupes. Ce que le noyau maintient est, pour chaque processus, un ID utilisateur (l' UID effectif ) et une liste d' ID de groupe (le GID effectif et les GID supplémentaires). Les groupes sont déterminés au moment de la connexion, par le processus de connexion - c'est le processus de connexion qui lit la base de données du groupe (par exemple /etc/group). Les ID utilisateur et groupe sont hérités par les processus enfants¹.

Lorsqu'un processus tente d'ouvrir un fichier, avec les autorisations Unix traditionnelles:

  • Si l'utilisateur propriétaire du fichier est l'UID effectif du processus, les bits d'autorisation utilisateur sont utilisés.
  • Sinon, si le groupe propriétaire du fichier est le GID effectif du processus ou l'un des ID de groupe supplémentaire du processus, les bits d'autorisation de groupe sont utilisés.
  • Sinon, les autres bits d'autorisation sont utilisés.

Un seul ensemble de bits rwx est jamais utilisé. L'utilisateur a priorité sur le groupe qui a priorité sur les autres. Lorsqu'il existe des listes de contrôle d'accès , l'algorithme décrit ci-dessus est généralisé:

  • S'il y a une ACL dans le fichier pour l'UID effectif du processus, elle est utilisée pour déterminer si l'accès est accordé.
  • Sinon, s'il y a une ACL dans le fichier pour le GID effectif du processus ou l'un des ID de groupe supplémentaires du processus, alors les bits d'autorisation de groupe sont utilisés.
  • Sinon, les autres bits d'autorisation sont utilisés.

Voir aussi Priorité d'ACLS lorsqu'un utilisateur appartient à plusieurs groupes pour plus de détails sur la façon dont les entrées ACL sont utilisées, y compris l'effet du masque.

-rw----r-- alice internsIndique ainsi un fichier qui peut être lu et écrit par Alice, et qui peut être lu par tous les autres utilisateurs à l'exception des stagiaires. Un fichier avec des autorisations et la propriété ----rwx--- alice internsest accessible uniquement aux stagiaires, sauf Alice (qu'elle soit stagiaire ou non). Étant donné qu'Alice peut appeler chmodpour modifier les autorisations, cela ne fournit aucune sécurité; c'est un cas de bord. Sur les systèmes avec ACL, le mécanisme généralisé permet de supprimer des autorisations d'utilisateurs ou de groupes spécifiques, ce qui est parfois utile.

L'utilisation d'un seul ensemble de bits, plutôt que de gérer tous les bits pour chaque action (lecture, écriture, exécution), présente plusieurs avantages:

  • Il a pour effet utile de permettre la suppression des autorisations d'un ensemble d'utilisateurs ou de groupes, sur les systèmes avec ACL. Sur les systèmes sans ACL, les autorisations peuvent être supprimées d'un groupe.
  • Il est plus simple à mettre en œuvre: vérifiez un ensemble de bits, plutôt que de combiner plusieurs ensembles de bits ensemble.
  • Il est plus simple d'analyser les autorisations d'un fichier, car moins d'opérations sont impliquées.

¹ Ils peuvent changer lorsqu'un processus setuid ou setgid est exécuté. Ce n'est pas lié au problème en question.

Gilles 'SO- arrête d'être méchant'
la source
eh bien ... par "effondrement", je voulais dire la même chose, une opération OU :)
alex
Merci pour votre temps; +1 pour la réponse très détaillée et assez technique
alex
Très bonne réponse. Mais j'ai une question sur vos derniers points: est-ce vraiment plus simple à mettre en œuvre et à analyser? La vérification des autorisations ne se résumerait-elle pas simplement à OU les autorisations ensemble comme le pensait OP était le cas?
gardenhead
Ce cas de bord me semble toujours idiot: (userX dans groupX) + (userZ dans groupX). Vous avez un fileX userX: groupX --- rwx ----. Le créateur du dossier d'origine userX ne peut plus accéder à fileX .. mais userZ le peut. Et ils font tous deux partie du même groupe. Vraiment pas intuitif.
alexfvolk
4

Les autorisations les plus spécifiques ont priorité sur les moins spécifiques.

userX dans groupX

fileX userX: groupX --- rwx ----

Étant donné que vous êtes le propriétaire du fichier, vous ne bénéficierez que des autorisations de propriétaire. Le propriétaire n'a aucune autorisation. Ainsi, vous ne pouvez rien faire. Si vous n'aviez pas été le propriétaire du fichier et un membre du groupe, les autorisations de groupe s'appliqueraient.

Veuillez lire cette section de la page wiki

https://en.wikipedia.org/wiki/File_system_permissions#Classes

kog
la source
2

-rwxrw---- signifie que le propriétaire a des autorisations de lecture, d'écriture et d'exécution, que le groupe a des autorisations de lecture et d'écriture et que d'autres n'ont aucune autorisation.

Les autorisations que vous avez fournies accordent au groupe «groupX» des autorisations pour lire, écrire et exécuter le fichier. Si vous êtes membre du groupe "groupX" mais pas le propriétaire du fichier, ces autorisations s'appliquent à vous.

Dans ce cas, je suppose que vous êtes bien le propriétaire du fichier. Seules les autorisations définies pour le propriétaire s'appliqueront alors à vous. Bien sûr, le propriétaire peut remplacer ou modifier les autorisations sur le fichier. Le groupe ne peut cependant pas le faire. Par exemple, vim vous demandera de confirmer si vous écrivez dans un fichier dont vous n'avez pas les autorisations d'écriture mais dont vous êtes le propriétaire.

Je lis généralement les autorisations de gauche à droite. Suis-je le propriétaire? Si oui, les autorisations du propriétaire s'appliquent. Si non; suis-je membre du groupe? Si oui, les autorisations de groupe s'appliquent. Sinon, les autorisations pour «Autre» s'appliquent à moi.

Dans certains cas, il est utile d'être propriétaire d'un fichier mais de ne pas avoir d'autorisations d'écriture. Il vous protège contre la suppression ou la modification accidentelle du fichier. Personnellement, j'ai défini l'autorisation 400 sur tous mes fichiers de modèle, juste pour m'assurer de ne pas les modifier par accident. Il en va de même pour les autorisations d'exécution.

arnefm
la source
1
Je crois que vous avez mal compris la question. Lorsque l'OP a dit que les autorisations "s'effondrent" en tant qu'Autres-> Groupe-> Utilisateur, je pense qu'elles signifiaient que lors de la détermination si votre action était autorisée, les autorisations "Autres" sont d'abord vérifiées, puis celles "Groupe" et enfin (si tout le reste échoue) "Utilisateur".
Joseph R.
@JosephR. yeap, c'est ce que je voulais dire :)
alex
Oh, mes excuses. Je vais supprimer cette partie. Y a-t-il quelque chose d'utile dans la réponse?
arnefm
Remarque: vous devez modifier un peu votre réponse et supprimer (ou reformuler) le deuxième paragraphe car il est un peu "obscur" (ce n'est pas assez clair, ce qui contredit le comportement que j'ai décrit)
alex
Après réflexion, j'aurais peut-être été trop rapide pour accepter la réponse. Désolé pour ça. Vous dites donc qu'il est parfois utile de ne pas avoir d'autorisations d'écriture afin de ne pas modifier accidentellement certains fichiers importants; mais à quoi cela sert-il lorsque d'autres ont des autorisations complètes? (alors ... vous serez empêché de faire des erreurs mais pas d' autres )
alex
0

J'ai pu ajouter un utilisateur à un groupe, donner des autorisations au groupe à un répertoire (070), puis APRÈS LE REDÉMARRAGE a pu accéder au dossier.

Créer un groupe: sudo groupadd groupname

Ajouter un utilisateur au groupe: sudo gpasswd -a nom d'utilisateur groupname

Assurez-vous que le répertoire entier est bien sous la propriété du groupe (doit être membre actuel du nom du groupe pour effectuer): sudo chgrp -R nom du groupe chemin_répertoire /

Donnez seulement le groupe rwx pour le dossier (peut être juste rw, ajustez si nécessaire): sudo chmod -R 070 directory_path

Après avoir fait ce qui précède, assurez-vous de vous déconnecter et de vous reconnecter. Si cela ne fonctionne pas, redémarrez la machine. Faire cela a fonctionné pour moi.

Justin Woods
la source
était usernamele propriétaire du répertoire? sinon, vous avez mal compris la question
alex