Unter welchem ​​Benutzer wird ein Linux-Skript/eine Linux-App ausgeführt?

Unter welchem ​​Benutzer wird ein Linux-Skript/eine Linux-App ausgeführt?

CentOS hier, aber ich glaube nicht, dass das wichtig ist, weil diessolleneine zentrale Linux-Frage sein (glaube ich). Beim Versuch, Apache Kafka (eine ausführbare Java-Datei) auf einer CentOS-Box zu installieren und auszuführen, fiel mir eine Frage ein, die für Linux im Allgemeinen gilt.

Wenn Sie ein Shell-Skript oder eine native ausführbare Datei (z. B. java) ausführen, bestimmt dann das Skript/die ausführbare Datei, als welcher Benutzer es ausgeführt wird, oder bestimmt das Betriebssystem, als welcher Benutzer das Skript/die ausführbare Datei ausgeführt wird (d. h., welcher Benutzer das Skript/die ausführbare Datei ausführt)?

Ist es möglich und/oder üblich, dass Prozesse vorgeben, unter welchem ​​Benutzer sie ausgeführt werden? BedeutungdürfenGibt ein Skript/eine Anwendung an, dass es/sie als Root-Benutzer oder als ein anderer bestimmter Benutzertyp ausgeführt werden muss?

Wie dem auch sei, warum gibt es eine allgemeine Ermahnung, Prozesse als Root auszuführen, anstatt sie als nicht privilegierter Benutzer auszuführen?

Antwort1

Kurze Antwort: beides.

Längere (und viel nützlichere) Antwort: Standardmäßig wird das Programm als der Benutzer ausgeführt, der es gestartet hat. Ein Programm kann jedoch, wenn es entsprechend geschrieben ist und die richtigen Berechtigungen hat, Root-Rechte annehmen und/oder auf einen „System“-Benutzer zurückgreifen, um sich selbst als Benutzer auszuführen. Diese Fähigkeit muss dem Programm jedoch ausdrücklich verliehen werden, entweder durch den Verpackungs- und Installationsprozess oder durch Aktionen, die vom Administrator dieses Computers ausgeführt werden.

Die allgemeine Warnung ist angebracht, weil die Erfahrung mit UNIX und Linux gezeigt hat, dass Programme, die erhöhte (also Root-)Privilegien verwenden, die sie nicht benötigen, dem System oft schaden. Das kann von Datenbeschädigungen über außer Kontrolle geratene Prozesse reichen, die den Rest des Systems unbrauchbar machen/nicht mehr reagieren lassen, bis hin zu Prozessen, die Angreifern unabsichtlich Zugriff auf Ihr System gewähren, und zwar auf eine Art und Weise, die Sie ihnen nicht erlauben.

Antwort2

Wenn ein „Shell-Skript“ ausgeführt wird, wird es mit den Berechtigungen des Benutzers ausgeführt, der dieses Skript ausgeführt hat. Die meisten Dienste (kafka, redis, nginx usw.), die mit einem Paketmanager (yum, apt usw.) installiert werden, installieren Hilfsskripte, um die Steuerung dieser Dienste zu erleichtern, und erstellen eindeutige Dienstbenutzer, die mit diesen Diensten verknüpft sind (apache, redis, nginx usw.). Fast alle dieser Hilfsskripte werden zunächst als Root ausgeführt und geben dann die Berechtigungen an einen diesem Dienst zugewiesenen Dienstbenutzer weiter. Dadurch wird sichergestellt, dass nur autorisierte Benutzer (d. h. Benutzer, die zum Ausführen von „sudo service kafka start“ berechtigt sind) diese Dienste effektiv steuern können. Dies bedeutet, dass die Systemadministratorin Sally Kafka und Nginx starten, stoppen und neu starten kann, während Entwickler Jim möglicherweise nur Kafka starten und stoppen kann (oder so ähnlich). Obwohl ein Java-Benutzer vom Administrator erstellt werden kann, habe ich dies in der Praxis nicht gesehen, ebenso wenig wie einen Ruby- oder Python-Benutzer. Vielmehr wird die Verantwortung für den Dienst häufiger einem Dienstbenutzer zugewiesen, der mit diesem bestimmten Dienst in Verbindung steht.

Manche Prozesse sind darauf angewiesen, als Root ausgeführt zu werden (normalerweise wird der SSH-Server-Daemon als Root ausgeführt). Andere Prozesse lassen sich nicht als Root starten (PostgreSQL ist einer davon).

Wenn Sie ein Hilfsskript für einen Dienst unter /etc/init.d/someservice (oder /etc/init/someservice.conf) überprüfen, sind die eigentlichen Skripte, die eine Rechteausweitung oder -verweigerung verursachen, dort codiert. Alternativ können Sie, wenn Sie als Benutzer Stephan angemeldet sind und etwas wie /usr/sbin/redis-server -c /etc/redis.conf ausführen und diesen Prozess dann in einem anderen Fenster überprüfen, feststellen, dass Redis Stephan gehört.

Hoffentlich hilft das.

verwandte Informationen