Autorisation refusée de changer le gid (groupe) d'un fichier que je possède


17

Il semble que je manque encore certaines choses sur le fonctionnement des autorisations. Je suis sur un système Debian 7 btw. en ce moment, j'ai ce fichier que j'ai téléchargé et auquel il appartient myuser:myuser, c'est-à-dire que l'utilisateur et le groupe sont définis pour moi. Il réside également dans mon $HOMErépertoire car c'est là que je l'ai téléchargé.

Jusqu'ici tout va bien. Maintenant, je veux partager ce fichier avec d'autres utilisateurs du PC et pour cela, je veux changer la propriété du groupe du fichier en groupe "utilisateurs". mais cela échoue:

nass@quarx:~/xmas_carol$ chgrp -R users * 
chgrp: changing group of movie.mov': Operation not permitted

Et le contenu du dossier est:

-rwxr-xr-x 1 nass nass 2482411461 Feb  6 03:57 movie.mov

Je suis flou sur ce qui se passe avec les autorisations. Quelqu'un peut-il expliquer


est le /xmas_carolmontage samba / nfs?
Rahul Patil

La solution est setfacl(si le système de fichiers a des ACL). voir unix.stackexchange.com/questions/101263/…
ctrl-alt-delor

J'ai eu la même erreur jusqu'à ce que je réalise que je m'étais AJOUTÉ à ce groupe. En d'autres termes, je devais me déconnecter, me reconnecter pour que les modifications prennent effet.
Jonathan

Réponses:


22

Votre utilisateur n'est probablement pas membre du usersgroupe, vous n'avez donc pas le droit de donner un fichier à ce groupe. Pour illustrer:

$ groups
terdon sudo netdev fuse vboxsf vboxusers

$ ls -l file
-rw-r--r-- 1 terdon terdon 604 Feb  6 03:04 file
$ chgrp users file
chgrp: changing group of ‘file’: Operation not permitted
$ chgrp vboxusers file
$ ls -l file
-rw-r--r-- 1 terdon vboxusers 604 Feb  6 03:04 file

Ce comportement est mentionné dans les spécifications POSIX :

Seul le propriétaire d'un fichier ou l'utilisateur disposant des privilèges appropriés peut changer le propriétaire ou le groupe d'un fichier.

Certaines implémentations limitent l'utilisation de chgrp à un utilisateur disposant des privilèges appropriés lorsque le groupe spécifié n'est pas l'ID de groupe effectif ou l'un des ID de groupe supplémentaires du processus appelant.

La raison principale en est que si vous n'êtes pas membre d'un groupe, vous ne devriez pas pouvoir modifier ce à quoi ce groupe a accès. Cette réponse sur les chownautorisations est également pertinente.

Traditionnellement, sur les systèmes partagés, vous avez un usersgroupe auquel appartiennent tous les utilisateurs réguliers et qui est le groupe principal de chaque utilisateur. De cette façon, les fichiers sont créés appartenant au usersgroupe et tous les utilisateurs peuvent les lire.

Quoi qu'il en soit, comme ce n'est pas la façon dont les distributions basées sur Debian sont installées ces jours-ci, la façon de donner à un utilisateur spécifique l'accès à votre fichier serait soit de

  1. Modifiez la propriété du groupe du fichier / répertoire en un groupe dont vous et l'autre utilisateur êtes membres;

  2. Modifiez simplement les autorisations du fichier / répertoire en conséquence:

    $ chmod 755 /home/terdon
    $ ls -ld /home/terdon
    drwxr-xr-x 170 terdon terdon 491520 Apr 20 13:43 /home/terdon/
    

    Cela rendra l'annuaire accessible à tous.


4

Sur les UNIC récents (et "récent" a une signification assez large ici), vous ne pouvez pas changer la propriété du groupe de fichiers en un groupe dont vous n'êtes pas membre. Les versions héritées de différentes versions UNIX prenaient en charge cela, pour des cas d'utilisation tels que le vôtre, mais cela s'est avéré être un problème de sécurité.

Le problème de pouvoir changer la propriété d'un groupe en groupes étrangers est assez trivial: si le système de fichiers sur lequel le fichier réside a des quotas de groupe activés, un utilisateur avec une intention malveillante pourrait simplement remplir le quota du groupe étranger, le rendant impossible pour les utilisateurs avec ce groupe comme ID de groupe principal pour créer d'autres fichiers. Cela pourrait facilement affecter même les processus déjà en cours d'exécution et les faire mourir à cause du "disque plein".

Pour contourner votre problème, il existe (au moins) deux possibilités: Tout d'abord, vous pouvez demander au superutilisateur de votre système d'ajouter le groupe cible souhaité à la liste des groupes supplémentaires de votre compte. Bien sûr, cela n'a de sens que si vous n'avez pas de relation avec ce groupe.

L'autre façon de ne pas avoir besoin de rendre le fichier accessible en écriture, ce qui n'est sûrement pas souhaité, consiste à utiliser des listes de contrôle d'accès pour donner au groupe prévu des autorisations de lecture et d'écriture:

$ setfacl -m group:thegroupsname:rwx the_file(s)

vous n'avez pas à donner execute (sur un fichier normal), et vous ne voulez probablement pas donner de permission d'écriture.
ctrl-alt-delor

2

Cela peut être dû au fait que le bit immuable est défini. Obtenez la liste des attributs de fichier en cours d'exécution

lsattr /path/to/your/file

si i apparaît, alors l'attribut immuable est défini et personne ne peut modifier le fichier (même root).

Pour supprimer l'attribut, vous devez exécuter en tant que root

chattr -i /path/to/your/file

Pour voir plus d'attributs du système de fichiers, lisez les pages de manuel

man chattr
man lsattr

Bon point, mais à partir de la question, je suppose que le questionneur n'a pas de droits de super-utilisateur, dont vous avez besoin pour effacer le drapeau immuable (au moins sur tous les systèmes de fichiers depuis si longtemps). De plus, comme il vient d'extraire une archive, ce n'est probablement pas le problème puisque l'archiveur utilisé aurait eu besoin de la définir (même problème).
Andreas Wiese

0

Si vous vous étiez ajouté au groupe tout à l'heure, déconnectez-vous, reconnectez-vous pour vous assurer que les modifications prennent effet.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.