Warum wird setuid in Verzeichnissen ignoriert?

Auf Linux-Systemen können Sie erfolgreich vorgehen chmod u+s $some_directory, aber anstatt den Besitz neuer Unterverzeichnisse und Dateien zu erzwingen, der Besitzer des enthaltenen Verzeichnisses zu sein (und auch Unterverzeichnisse festzulegen u+s), wie Sie es vielleicht erwarten würden, ignoriert das System einfach das setuid-Bit. Unterverzeichnisse und Dateien übernehmen weiterhin die UIDs ihrer Erstellungsprozesse, und Unterverzeichnisse werden standardmäßig nicht festgelegt.

Warum wird setuid in Verzeichnissen ignoriert und wie kann ich das System dazu bringen, es zu erkennen?

Erinnern Sie sich daran, dass die Bits setuid und setgid für einen völlig anderen Zweck erfunden wurden: Die Ausführung einer ausführbaren Datei mit der Benutzer-ID oder der Benutzer-ID des Besitzers und nicht mit der Benutzer-ID oder der Benutzer-ID des Benutzers, der die Datei ausführt. Jede andere Verwendung ist nur eine zusätzliche Funktion.

Diese Bits haben keine Funktion für normale Dateien, die nicht ausführbar sind. (Und aus Sicherheitsgründen auch Shell-Skripte in einigen Distributionen.) Ursprünglich hatten sie auch keine Funktion für Verzeichnisse. Offensichtlich hat jemand entschieden, dass es cool wäre, die nicht verwendete setgid für Verzeichnisse zu verwenden, um die Konsistenz der Gruppeneigentümer zu erzwingen. Wenn Sie mit Gruppeneigentum spielen, liegt dies daran, dass mehr als eine Person mit der Datei arbeitet, und es ist wahrscheinlich sinnvoll, dass alle Dateien in einem bestimmten Verzeichnis derselben Gruppe angehören, unabhängig davon, wer sie erstellt hat. Probleme, die dadurch entstehen, dass jemand vergisst, newgrp zu betreiben, werden beseitigt.

Warum also nicht dasselbe Feature für setuid und die Datei uid implementieren? Nun, UID ist viel einfacher als GID. Wenn Sie dies implementieren, gehört eine Datei häufig 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. Es ist schwer zu erkennen, wie nützlich das ist.

Ich glaube, dass die Antwort auf diese Frage die "File Giveaway" -Sicherheitsprobleme betrifft, die dazu geführt haben, dass die meisten modernen Unix-ähnlichen Betriebssysteme "File Giveaway" nicht zulassen. "Datei-Werbegeschenk" ist, wenn ein Benutzer, der kein Superuser ist, den Besitz einer Datei an eine andere Person als diesen Benutzer ändert. Diese Fähigkeit bietet viele Möglichkeiten für Unfug.

Da Datei-Werbegeschenke nicht zulässig sind, ist setuid für Verzeichnisse, die dieselbe Funktion in einer anderen Form ausführen würden, nicht zulässig oder wird ignoriert, wenn sie festgelegt sind.

Um das Verhalten zu ändern, müssten Sie die Betriebssystembibliotheken und Dienstprogramme ändern.

Ein sehr guter Anwendungsfall für die Implementierung ist folgender:

Nehmen wir an, Sie haben einen Server mit mehreren Standorten und drei sicheren Standorten. Sie haben 3 Gruppen erstellt, eine für jeden der verschiedenen Site-Betreuer. Alle Dateien auf allen Websites müssen dem Apache-Benutzer gehören, damit Apache sie lesen und darauf schreiben kann (Drupal / WordPress usw.).

Wenn die setuid aber wie das setgid-Bit für Verzeichnisberechtigungen funktionieren würde, würde dies 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 darauf, nur ihren Inhalt zu sehen und zu berühren, aber der Webserver-Benutzer Apache konnte den gesamten Inhalt bereitstellen, und es besteht keine Notwendigkeit für Benutzer, sich Gedanken über das Ändern des Eigentums an hochgeladenen Dateien zu machen.

Ein weiterer Anwendungsfall ist für anonyme FTP / HTTP- oder sogar SFTP / SSH-Uploads. Die Gruppe und die GID im Upload-Verzeichnis wären root, ebenso wie 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 nach dem Upload nichts mehr lesen, und root würde alle neu erstellten Dateien besitzen.

Es gibt also zwei sehr gute und gültige Anwendungsfälle, um die UID-Funktionalität in Verzeichnissen so zu aktivieren, dass sie mit dem GID-Bit übereinstimmt.

Steven Mercurio

Ein bisschen zu spät zur Party, aber für den Fall, dass zukünftige Leser darüber stolpern;) Wie von anderen angegeben, wird auf einem Standard-OS-X-Dateisystem die setUID für Verzeichnisse ignoriert - und es scheint keinen einfachen Weg zu geben, dies zu umgehen ( mount -o.... oder was nicht). Wie so oft entspricht die Manpage nicht dem OS-X-Verhalten, das sie wörtlich angibt:

4000 (das Set-User-ID-On-Execution-Bit) [...] Verzeichnisse mit dem Set-User-ID-Bit erzwingen, dass alle darin erstellten Dateien und Unterverzeichnisse dem Verzeichnisbesitzer und nicht von gehören Die Benutzeroberfläche des Erstellungsprozesses [...]

es wird jedoch auch eine Möglichkeit aufgeführt, den gleichen Effekt zu erzielen, ohne das ursprüngliche Eigentum aufzugeben. Linux verwendet '[g /] setfacls' für ähnliche Effekte (diese Berechtigungen sind auf den ersten Blick nicht wirklich sichtbar und können daher manchmal lästig sein).

Lesen Sie die gesamte Manpage, um zu erfahren, wie Sie ähnliche Effekte erzielen können.

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

Sie können über überprüfen

ls -le

wenn alles gut aussieht. Weitere Optionen sind das Einfügen von Regeln an bestimmten Positionen sowie das Entfernen oder Ersetzen bestimmter Regeln. Die beiden bemerkenswerten Optionen sind " file_inheritund directory_inherit", mit denen die Regeln an ein neues Verzeichnis / eine neue Datei angehängt werden können.

Ich verwende setUID nicht besonders gern, aber setGID ist sehr praktisch bei Dateiservern, bei denen das einfache Festlegen der Hauptgruppe nicht funktioniert oder Clients Dateimasken haben, die das Schreiben von Gruppen nicht zulassen. Das würde gelöst werden durch:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Nun, es sollte den Standard respektieren. Ich kann bei einigen Szenarien mit SFTP-Only denken, dass es mir eine Menge Ärger ersparen würde, sowohl mit ACLs als auch mit dem ACL-Mask-Set, das SSHD macht, und dem Reset, das ich mit dieser Maske machen muss.

Standardmäßig ist die Sicherheit ziemlich nützlich, aber wenn Sie diese Option nicht aktivieren, erstellen Sie nur eine Winghtmare.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

Wie auch immer, es ist so, wie es Linux jetzt macht, also benutze einfach acls, um diese zu umgehen.

Gemäß http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories wird das setuid-Bit für Verzeichnisse auf UNIX- und Linux-Systemen ignoriert. Es ist jedoch möglich, es so zu machen, wie Sie es von FreeBSD erwarten.