Impossible de lire un fichier bien qu'il soit dans mon groupe et que les autorisations de lecture de groupe soient définies

14

Je rencontre un étrange problème sur une machine unix / linux:

Je suis membre d'un groupe, appelons-le groupe A et un certain fichier (qui a un propriétaire différent) appartient également au groupe A. Les autorisations de ce fichier sont

-rw-rw----

je m'attends donc à ce que je puisse ouvrir ce fichier, mais je ne le suis pas: j'obtiendrai le message d'erreur "Autorisation refusée" lorsque j'essaierai de regarder le contenu du fichier (en utilisant cat).

Étant donné que les autorisations semblent être correctes, quoi d'autre pourrait être à l'origine de cela? Y a-t-il des restrictions d'autorisation "prioritaires" en place? Si oui, comment pourrais-je le savoir?

— Lagerbaer
source

2

Qu'en est-il des autorisations de répertoire?

— Karlson

Si vous êtes dans plusieurs groupes, votre groupe actuel est-il défini sur A?

— Code-Guru

2

@Karlson, si les autorisations de répertoire étaient le problème, vous ne seriez pas en mesure de voir les autorisations du fichier en premier lieu.

— cjm

Montrez-nous le chemin complet et le nom du fichier s'il vous plaît.

— jippie

C'est dans /home/theotheruser/somefolder/bla.txt Je suis dans plusieurs groupes.

— Lagerbaer

8

Vous êtes-vous déconnecté et reconnecté depuis que vous avez été ajouté au groupe A?

Si ce n'est pas le cas, vos processus de connexion actuels n'auront que les appartenances au groupe qu'ils avaient au moment de la connexion, pas de modifications depuis. Et tous les processus enfants de cette connexion auront les mêmes appartenances de groupe (c'est-à-dire si vous vous êtes connecté à X, alors chaque application, y compris votre émulateur de terminal et votre shell)

Vous pouvez tester cela en vous connectant à nouveau sur une autre console ou via ssh, ou quelque chose comme exec sudo -u $(id -u -n) -i(pour tuer et remplacer efficacement le shell actuel par un nouveau shell - tous les processus d'arrière-plan appartenant à ce shell seront orphelins)

— cas
source

Non, ce n'était pas le problème; Je me suis déconnecté et reconnecté et cela ne l'a pas résolu.

— Lagerbaer

3

Avec NFS, cela dépend du mode de sécurité que vous utilisez, mais dans le mode traditionnel, la liste des groupes auxquels l'utilisateur appartient est envoyée par le client au serveur, et il y a une limite sur le nombre de groupes qui peuvent être envoyés (c'était 16 la dernière fois que j'ai vérifié).

Donc, le client dit: je suis uid 1234 et d'ailleurs je suis membre des groupes 12, 13, 14 ... Si vous êtes dans plus de 16 groupes, cette liste sera tronquée et il y aura des groupes pour dont le serveur ne sait pas que vous en êtes membre.

Voilà probablement l'explication. Seul l'administrateur système de la machine locale et / ou distante peut y remédier en modifiant le modèle de sécurité ou les paramètres du serveur NFS ou en réduisant le nombre de groupes dont vous êtes membre.

— Stéphane Chazelas
source

J'ai le fort sentiment que c'est la raison, parce que le groupe que je suis apparaît à la position 19 dans la sortie de la commande "groups". Je vais montrer cette réponse à l'administrateur système et voir si cela aide. :)

— Lagerbaer

Comment changeriez-vous le "modèle de sécurité" sur NFS pour résoudre ce problème?

— Danny

2

Comme vous le notez dans un commentaire, vous ne disposez pas des autorisations de lecture pour /home/username. Mais pour lire /home/username/path1/path2/file, vous devez exécuter des autorisations pour l'ensemble du chemin.

Pour déboguer cela, exécutez en namei -l /home/username/path1/path2/filetant qu'utilisateur qui lit le fichier.

— Adam Trhon
source

C'était le problème dans mon cas. Je voulais donner à un autre utilisateur le droit d'opérer sur le sous-dossier de mon répertoire personnel, mais mon répertoire personnel a accès à 700, donc ils ont obtenu "Autorisation refusée" pour toute commande.

— Cerberus

1

Il peut s'agir d'ACL. Voir

getfacl the-file

Cela pourrait être dû au fait que les groupes auxquels vous êtes censé appartenir ne sont pas correctement définis. Vérifier avec

id -a

Qu'en est-il de

namei -xl "$(readlink -f the-file)"

getfattr -dm- the-file

sudo lsattr the-file

Quel est le type de système de fichiers dans lequel il réside?

Un apparmor, SELinux ou tout autre contrôle d'accès obligatoire en place dans le système?

Vous êtes sûr que le fichier ne contient pas le texte "Autorisation refusée", non ;-)?

— Stéphane Chazelas
source

Non, il n'y a pas d'ACL spéciale, il répète simplement ce que les drapeaux standard me disent, et id -a me dit que je suis dans le groupe de ce fichier

— Lagerbaer

Ce qui est bizarre, c'est que je peux voir les fichiers d'un autre utilisateur appartenant au groupe B, dont je suis également membre ...

— Lagerbaer

Le système de fichiers semble être nfs4. namei me donne / et la maison appartenant à root, root. / home / nom d'utilisateur appartenant au nom d'utilisateur et au groupe X (dont je ne suis pas membre), le reste est / home / nom d'utilisateur / path1 / path2 / fichier où path1 appartient au nom d'utilisateur et au groupe X, et path2 appartient au nom d'utilisateur, et groupe A, dont je suis membre.

— Lagerbaer