Erinnern Sie sich, dass die setuid- und setgid-Bits für einen ganz anderen Zweck erfunden wurden:eine ausführbare Datei dazu zu bringen, mit der uid oder gid ihres Besitzers zu laufen, anstatt mit der uid oder gid des Benutzers, der die Datei ausführt. Jede andere Verwendung ist nur ein zusätzliches Feature.
Bei gewöhnlichen Dateien, die nicht ausführbar sind, haben diese Bits keine Funktion. (Und aus Sicherheitsgründen auch Shell-Skripte auf einigen Distributionen.) Ursprünglich hatten sie auch keine Funktion für Verzeichnisse. Offensichtlich hat jemand entschieden, dass es cool wäre, die unbenutzte setgid auf Verzeichnisse zu nehmen und sie zu verwenden, um die Konsistenz des Gruppenbesitzes zu erzwingen. Wenn Sie mit Gruppenbesitz spielen, liegt das schließlich daran, dass mehr als eine Person mit der Datei arbeitet, und es wahrscheinlich sinnvoll ist, dass alle Dateien in einem bestimmten Verzeichnis zur selben Gruppe gehören, unabhängig davon, wer sie erstellt hat. Ärger, weil jemand vergessen hat, newgrp auszuführen, wird eliminiert.
Warum also nicht dieselbe Funktion für setuid und die Datei-uid implementieren? Nun, uid ist viel grundlegender als gid. Wenn Sie dies implementieren, gehört eine Datei oft nicht dem Benutzer, der sie erstellt hat! Vermutlich kann der Benutzer die Datei immer noch ändern (vorausgesetzt, die umask ist etwas Vernünftiges), aber er kann die Berechtigungsbits nicht ändern. Der Nutzen davon ist schwer zu erkennen.
Ich glaube, dass die Antwort auf diese Frage sich auf die Sicherheitsprobleme des "Datei-Werbens" bezieht, die dazu geführt haben, dass die meisten modernen Unix-ähnlichen Betriebssysteme "Datei-Werben" nicht zulassen. „Dateivergabe“ liegt vor, wenn ein Nicht-Superuser-Benutzer den Besitz einer Datei an jemand anderen als diesen Benutzer ändert. Diese Fähigkeit bietet viele Gelegenheiten für Unfug.
Da Datei-Werbegeschenke nicht erlaubt sind, ist setuid für Verzeichnisse, die die gleiche Funktion in einer anderen Form ausführen würden, nicht erlaubt oder wird ignoriert, wenn sie gesetzt ist.
Um das Verhalten zu ändern, müssten Sie Betriebssystembibliotheken und Dienstprogramme ändern.
Ein sehr guter Anwendungsfall für die Implementierung ist dieser:
Nehmen wir an, Sie haben einen Multi-Site-Server mit 3 sicheren Sites. Sie haben 3 Gruppen erstellt, eine für jeden der verschiedenen Site-Betreuer. Alle Dateien auf allen Sites müssen Eigentum des Apache-Benutzers sein, damit Apache sie lesen und darauf schreiben kann (Drupal/Wordpress usw.).
Wenn die setuid aber so funktionieren würde wie das setgid-Bit für Verzeichnisberechtigungen würde es ungefähr so aussehen:
/var/www/sitea - apache:groupa rwS rwS ---
/var/www/siteb - apache:groupb rwS rwS ---
/var/www/sitec - apache:groupc rwS rwS ---
Auf diese Weise hatte jede Gruppe von Betreuern Zugriff, um nur ihre Inhalte zu sehen und zu berühren, aber der Webserver-Benutzer Apache konnte alle Inhalte bereitstellen, und die Benutzer mussten sich keine Gedanken darüber machen, den Besitz der hochgeladenen Dateien zu ändern.
Ein weiterer Anwendungsfall sind anonyme FTP/http- oder sogar sftp/ssh-Uploads. Die Gruppe und die GID im Upload-Verzeichnis wären root, ebenso der Eigentümer und die UID. Die anderen Berechtigungen wären -wx . Dies würde jedem SCHREIBEN-Zugriff auf das Upload-Verzeichnis ermöglichen, aber er könnte nichts lesen, sobald es hochgeladen wurde, und root würde alle neu erstellten Dateien besitzen.
Es gibt also zwei absolut gute und gültige Anwendungsfälle, um die UID-Funktionalität für Verzeichnisse zu aktivieren, damit sie mit dem GID-Bit übereinstimmen.
Steven Mercurio