Das Verhalten von Hardlink-Berechtigungen unterscheidet sich zwischen CentOS 6 und CentOS 7


8

Ich erhalte einen Berechtigungsfehler in CentOS 7, wenn ich versuche, einen festen Link zu erstellen. Mit den gleichen Berechtigungen, die in CentOS 6 festgelegt wurden, wird der Fehler nicht angezeigt. Das Problem konzentriert sich auf Gruppenberechtigungen. Ich bin nicht sicher, welche Betriebssystemversion richtig und welche falsch ist.

Lassen Sie mich veranschaulichen, was passiert. In meinem aktuellen Arbeitsverzeichnis habe ich zwei Verzeichnisse: Quelle und Ziel. Zu Beginn ist das Ziel leer. Quelle enthält eine Textdatei.

[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]# 

Wie Sie sehen können, sind die beiden Verzeichnisse in Bezug auf die Berechtigungen 777, wobei sowohl der Eigentümer als auch die Gruppe auf root festgelegt sind. Der Eigentümer und die Gruppe der Textdatei sind ebenfalls auf root festgelegt. Die Berechtigungen der Textdatei sind jedoch für den Eigentümer schreibgeschützt, für die Gruppe jedoch schreibgeschützt.

Wenn ich als root angemeldet bin, kann ich problemlos einen Hardlink im Zielverzeichnis erstellen, der auf die Textdatei (im Quellverzeichnis) verweist.

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

Wenn ich mich jedoch als ein anderer Benutzer anmelde, in diesem Fall als Administrator, kann ich den Link nicht erstellen. Ich bekomme: "Operation nicht erlaubt."

[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

Was passiert, macht für mich tatsächlich Sinn, aber da das oben Genannte in CentOS 6 erlaubt ist, wollte ich überprüfen, ob ich etwas falsch verstanden habe. Für mich scheint es ein Fehler in CentOS 6 zu sein, der in CentOS 7 behoben wurde.

Weiß jemand was gibt? Habe ich recht, dass das obige Verhalten das richtige ist? Ist CentOS 6 richtig? Oder haben beide Recht und vielleicht fehlt mir ein subtiles Problem mit Gruppenberechtigungen? Vielen Dank.


Bearbeiten: Ich habe den gleichen Test gerade auf einer Debian v7-VM versucht, die ich habe. Debian stimmt CentOS 7 zu: "Betrieb nicht erlaubt."


Edit # 2: Ich habe gerade dasselbe unter Mac OS X (Yosemite) versucht. Das hat genauso funktioniert wie CentOS 6. Mit anderen Worten, der Link konnte erstellt werden. (Hinweis: Unter OS X heißt die Stammgruppe "Rad". Soweit ich das beurteilen kann, ist dies der einzige Unterschied.)


1
Es scheint, dass der Benutzeradministrator keine Berechtigungen hat, den Link zu beeinflussen. Das Eigentum an dem Link hängt davon ab, wem die zu verlinkenden Dateien / Ordner gehören. Admin ist nicht dasselbe wie root. Das sind meine 2 Cent. Versuchen Sie als Administrator, 'sudo ln source / test.txt destination /' zu verwenden. Möglicherweise möchten Sie auch das Flag -s verwenden. Wenn Sie einen Link ohne das Flag -s erstellen, erstellen Sie einen festen Link. Es ist ein Rezept für eine Katastrophe, denn wenn die verknüpfte Datei / der verknüpfte Ordner zerstört wird, ist auch das Original zerstört. Mit -s 'Softlinks' wirkt sich die Zerstörung der mit der Datei verknüpften Datei nicht auf das Original aus.
Baazigar

@ Baazigar - Danke. Ich habe das untersucht. Hier ist mein Problem. Ich habe eine Perl-Anwendung geerbt, die sich auf das Verhalten von CentOS 6 stützt (in der Lage zu sein, den Link zu erstellen). Ich migriere die Anwendung auf CentOS 7. Dies ist eigentlich nur ein kleines Problem im Gesamtschema der Dinge, aber ich weiß nicht, warum die Perl-Link-Funktion anstelle der Perl File :: Copy-Funktion verwendet wird. Ich denke, es würde ausreichen, nur die Datei zu kopieren. Ich muss jedoch meine Sorgfalt walten lassen, bevor ich etwas ändere - und es gibt (natürlich) keine Dokumentation oder Kommentare, um die ursprüngliche Entscheidung zu erklären, die ich geerbt habe.
Mario

Ohne Dokumentation oder Begründung für den aktuellen Stand ist Ihre Lösung gleichermaßen gültig, sofern sie funktioniert, und gültiger, wenn sie funktioniert und über Dokumentation verfügt. Ich glaube nicht, dass sich die Handhabung der Links durch Centos geändert hat. Ich denke, es ist wahrscheinlicher, dass Sie auf der alten Box noch nicht auf etwas gestoßen sind, vielleicht etwas in / etc / group oder an einem anderen Ort, das die offensichtliche Anomalie erklärt.
Baazigar

@Baazigar - Ich habe gerade das Gleiche unter Mac OS X versucht, obwohl ich anstelle der Gruppe "root" die Gruppe "Rad" (Root-Gruppe) verwenden musste. Wie Sie vielleicht wissen, ist OS X eine BSD-Variante. Das funktionierte genauso wie CentOS 6 - mit anderen Worten, es ermöglichte die Herstellung der Verknüpfung. Ich weiß derzeit nicht, was richtig ist. Sollte es nicht eine einheitliche Vorgehensweise für (meistens) POSIX-kompatible Systeme geben?
Mario

Antworten:


5

Ich habe einige neue CentOS 6 und 7 VMs hochgefahren und konnte das genaue Verhalten, das Sie gezeigt haben, wiederherstellen. Nach einigem Graben stellt sich heraus, dass dies aus Sicherheitsgründen tatsächlich eine Änderung im Kernel in Bezug auf das Standardverhalten in Bezug auf Hard- und Soft-Links ist. Die folgenden Seiten haben mich in die richtige Richtung gelenkt:

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

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

Wenn Sie die Dateiewelt beschreibbar machen, kann Ihr Administrator den Hardlink erstellen.

Um zum systemweiten Verhalten von CentOS 6 zurückzukehren, wurden neue Kernelparameter hinzugefügt. Stellen Sie in /etc/sysctl.conf Folgendes ein:

fs.protected_hardlinks = 0
fs.protected_symlinks = 0

dann renne

sysctl -p

Warum Ihr Programm Links verwendet, anstatt Dateien zu kopieren, warum eine exakte Kopie einer Datei erstellen, die Sie verwenden müssen, wenn Sie nur einen Eintrag erstellen können, der auf die Originalblöcke verweist? Dies spart Speicherplatz und der Betrieb ist in Bezug auf CPU und E / A weniger kostspielig. Der neue Hardlink ist dieselbe Datei, nur mit unterschiedlichen Metadaten / Inode. Wenn Sie die Originaldatei nach dem Erstellen eines festen Links löschen, hat dies keine Auswirkungen auf den Link. Eine Datei wird erst gelöscht, wenn alle Links entfernt wurden.


Vielen Dank. Ich werde mir diese Links heute etwas später ansehen. (In der Zwischenzeit eine positive Bewertung!) Ich verstehe den Unterschied zwischen einem harten Link und einer Kopie. Das Programm, das ich geerbt habe, erstellt jedoch einen Link von der Quelldatei zu einem "Download" -Bereich (über ein Webanwendungs-Frontend). Ich denke nicht, dass Speicherplatz ein Problem ist, da es nur eine Textdatei ist. Wenn ich nur das betrachte, was "Download" normalerweise bedeutet, verstehe ich nicht, wie ein Link hineinpasst: Semantisch scheint eine Kopie sinnvoller zu sein. (Ich mache mir Sorgen, dass es ein anderes Verhalten im Programm gibt, das auf einem Link beruht. Ich muss es überprüfen.)
Mario

1
"Ich verstehe den Unterschied zwischen einem harten Link und einer Kopie." Richtig, ich habe meine Antwort nur für ein allgemeines Publikum geschrieben, damit zukünftige Benutzer sie lesen können, die es vielleicht nicht wissen.
Sean

Ich bin alles für das Schreiben für ein allgemeines Publikum :-) Ich werde am Montag die beste Lösung für die Anwendung untersuchen. Zum Glück habe ich viel Spielraum. (Meine einzige Einschränkung ist "Sie brechen es; Sie haben es gekauft"!) Ich markiere Ihre als akzeptierte Antwort. Danke noch einmal!
Mario

PS Ich vermute, dass sich die CentOS-Leute standardmäßig für geschützte Links entschieden haben. (Was ich von den von Ihnen angegebenen Links erhalte, ist, dass dies ein umstrittenes Thema ist.)
Mario
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.