Comportement des autorisations de liaison fixe différent entre CentOS 6 et CentOS 7

8

Je reçois une erreur d'autorisation dans CentOS 7 lorsque j'essaie de créer un lien dur. Avec les mêmes autorisations définies dans CentOS 6, je ne reçois pas l'erreur. Le problème est centré sur les autorisations de groupe. Je ne sais pas quelle version du système d'exploitation est correcte et laquelle est incorrecte.

Permettez-moi d'illustrer ce qui se passe. Dans mon répertoire de travail actuel, j'ai deux répertoires: source et destination. Au début, la destination est vide; la source contient un fichier texte.

[root@tc-dlx-nba cwd]# ls -l
total 0
drwxrwxrwx. 2 root root  6 Jun 12 14:33 destination
drwxrwxrwx. 2 root root 21 Jun 12 14:33 source
[root@tc-dlx-nba cwd]# ls -l destination/
total 0
[root@tc-dlx-nba cwd]# ls -l source/
total 4
-rw-r--r--. 1 root root 8 Jun 12 14:20 test.txt
[root@tc-dlx-nba cwd]#

Comme vous pouvez le voir, en ce qui concerne les autorisations, les deux répertoires sont 777, avec le propriétaire et le groupe définis sur root. Le propriétaire et le groupe du fichier texte sont également définis sur root. Cependant, les autorisations du fichier texte sont en lecture-écriture pour le propriétaire mais en lecture seule pour le groupe.

Lorsque je suis connecté en tant que root, je n'ai aucun problème à créer un lien dur dans le répertoire de destination pointant vers le fichier texte (dans le répertoire source).

[root@tc-dlx-nba cwd]# ln source/test.txt destination/
[root@tc-dlx-nba cwd]# ls destination/
test.txt

Cependant, si je me connecte en tant qu'autre utilisateur, dans ce cas, admin, je ne peux pas créer le lien. J'obtiens: "Opération non autorisée."

[root@tc-dlx-nba cwd]# rm -f destination/test.txt 
[root@tc-dlx-nba cwd]# su admin
bash-4.2$ pwd
/root/cwd
bash-4.2$ ln source/test.txt destination/
ln: failed to create hard link ‘destination/test.txt’ => ‘source/test.txt’: Operation not permitted

Ce qui se passe a du sens pour moi, mais comme ce qui précède est autorisé dans CentOS 6, je voulais vérifier si j'avais mal compris quelque chose. Pour moi, cela ressemble à un bogue dans CentOS 6 qui a été corrigé dans CentOS 7.

Quelqu'un sait ce qui donne? Ai-je raison de croire que le comportement ci-dessus est le bon comportement? Est-ce CentOS 6 qui est correct? Ou, ont-ils raison et peut-être qu'il y a un problème subtil d'autorisations de groupe qui me manque? Merci.

Edit: J'ai essayé le même test tout à l'heure sur une machine virtuelle Debian v7 que j'ai. Debian est d'accord avec CentOS 7: "Opération non autorisée."

Edit # 2: Je viens d'essayer la même chose sur Mac OS X (Yosemite). Cela a fonctionné comme CentOS 6 l'a fait. En d'autres termes, cela a permis de créer le lien. (Remarque: Sous OS X, le groupe racine est appelé «roue». C'est la seule différence, pour autant que je sache.)

centos permissions hard-link Mario
la source
1
Il semble que l'administrateur utilisateur n'ait pas les autorisations pour affecter le lien. La propriété du lien dépend de qui possède les fichiers / dossiers liés. L'administrateur n'est pas la même chose que root. C'est mes 2 cents. En tant qu'administrateur, essayez d'utiliser 'sudo ln source / test.txt destination /'. Vous pouvez également commencer à utiliser l'indicateur -s. Lorsque vous créez un lien sans l'indicateur -s, vous créez un lien dur. C'est une recette pour un désastre car si le fichier / dossier lié est détruit, l'original aussi. Avec -s 'soft links' la destruction du fichier lié n'affecte pas l'original.
Baazigar
@Baazigar - Merci. J'ai examiné cela. Voici mon problème. J'ai hérité d'une application Perl qui s'appuie sur le comportement de CentOS 6 (pouvoir créer le lien). Je migre l'application vers CentOS 7. C'est vraiment juste un petit problème dans le schéma global des choses, mais je ne sais pas pourquoi la fonction de lien Perl est utilisée, au lieu de la fonction Perl File :: Copy. Je pense qu'il suffirait de copier le fichier. Cependant, je dois faire preuve de diligence raisonnable avant de changer les choses - et il n'y a (bien sûr) aucun document ni commentaire pour expliquer la décision initiale dont j'ai hérité.
Mario
Sans documentation ni justification de la façon dont elle est maintenant, votre solution est également valable en supposant qu'elle fonctionne, et plus valable si elle fonctionne et possède de la documentation. Je ne pense pas qu'il y ait eu un changement dans la gestion des liens par les centos. Je pense que c'est probablement quelque chose que vous n'avez pas encore rencontré sur l'ancienne boîte, peut-être quelque chose dans / etc / group ou ailleurs qui explique l'anomalie apparente.
Baazigar
@Baazigar - J'ai juste essayé la même chose sous Mac OS X, même si j'ai dû utiliser le groupe "wheel" (groupe de root) à la place du groupe "root". Comme vous le savez peut-être, OS X est une variante BSD. Cela fonctionnait de la même manière que CentOS 6 - en d'autres termes, cela permettait d'établir le lien. Je ne sais pas ce qui est bien, à ce stade. Ne devrait-il pas y avoir une pratique unifiée sur tous les systèmes compatibles POSIX (principalement)?
Mario

Réponses:

5

J'ai fait tourner de nouveaux CentOS 6 et 7 vm et j'ai pu recréer le comportement exact que vous avez montré. Après avoir creusé, il s'avère que c'est en fait un changement dans le noyau concernant le comportement par défaut en ce qui concerne les liens durs et mous pour des raisons de sécurité. Les pages suivantes m'ont indiqué la bonne direction:

http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415

http://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1

Si vous rendez le monde du fichier accessible en écriture, votre utilisateur administrateur pourra créer le lien dur.

Pour revenir au comportement du système CentOS 6 à l'échelle du système, de nouveaux paramètres du noyau ont été ajoutés. Définissez les éléments suivants dans /etc/sysctl.conf:

fs.protected_hardlinks = 0
fs.protected_symlinks = 0

puis exécutez

sysctl -p

Quant à savoir pourquoi votre programme choisit d'utiliser des liens au lieu de copier des fichiers, pourquoi créer une copie exacte d'un fichier que vous devez utiliser lorsque vous pouvez simplement créer une entrée qui pointe vers les blocs d'origine? Cela économise de l'espace disque et l'opération est moins coûteuse en termes de CPU et d'E / S. Le nouveau lien dur est le même fichier, juste avec des métadonnées / inodes différents. Si vous deviez supprimer le fichier d'origine après avoir créé un lien dur, cela n'affectera pas le lien. Un fichier n'est «supprimé» qu'une fois tous les liens supprimés.

Sean
la source
Je vous remercie. J'examinerai ces liens un peu plus tard dans la journée. (Avoir un vote positif en attendant!) Je comprends la différence entre un lien dur et une copie. Le programme dont j'ai hérité, cependant, crée un lien à partir du fichier source vers une zone de "téléchargement" (via un frontal d'application Web). Je ne pense pas que l'espace disque soit un problème, car il s'agit simplement d'un fichier texte. De plus, en me basant sur ce que signifie généralement "télécharger", je ne comprends pas comment un lien s'intègre: sémantiquement, une copie semble avoir plus de sens. (Je crains qu'il y ait un autre comportement dans le programme qui repose sur un lien. Je vais devoir vérifier.)
Mario
1
"Je comprends la différence entre un lien dur et une copie." Righton, je venais d'écrire ma réponse avec un public général à l'esprit pour les futurs utilisateurs qui ne le savent peut-être pas.
Sean
Je suis tout à fait pour écrire avec un public général à l'esprit :-) Je vais enquêter sur la meilleure solution pour l'application, lundi. Heureusement, j'ai beaucoup de latitude. (Ma seule contrainte est "vous le cassez; vous l'avez acheté"!) Je marque la vôtre comme la réponse acceptée. Merci encore!
Mario
PS Je suppose que les gens CentOS ont opté pour les liens protégés par défaut. (Ce que j'obtiens des liens que vous avez fournis, c'est qu'il s'agit d'un problème litigieux.)
Mario