Was ist der Zweck des Benutzers "nobody"?


93

Nachdem ich List all human users gelesen hatte, bemerkte ich, dass sich in meinem Ubuntu-System ein Benutzerkonto namens nobody befindet.

Außerdem habe ich festgestellt, dass ich mich mit folgendem Befehl und meinem Passwort vom Terminal aus in dieses Konto einloggen kann:

sudo su nobody

so niemand

Es stört mich überhaupt nicht, aber ich möchte wissen, was der Zweck dieses Benutzers ist? Wird es standardmäßig bei einer Neuinstallation von Ubuntu erstellt oder wird es durch die Installation eines bestimmten Pakets erstellt?


8
Beachten Sie, dass Sie bei der Anmeldung mit Ihrem Passwort Ihr Passwort für den Schritt sudo verwenden, nicht für das Konto nobody (und dass dies deshalb funktioniert, weil der Superuser für jeden eine Klage erheben kann, ohne sein Passwort eingeben zu müssen (obwohl als Ich glaube, zumindest bei RH-Derivaten, wenn die Shell von niemandem auf / sbin / nologin gesetzt ist, könnten Sie sich immer noch nicht einmal mit dem Superuser (alias root) anmelden
Foon

Das ist jetzt standardmäßig der Fall (18.04+?). sudo su nobodyreturn Dieses Konto ist derzeit nicht verfügbar. weil die Shell für den Benutzer nobody auf/usr/sbin/nologin ( getent passwd nobody) gesetzt ist.
Pablo A

@sarnold - Bitte lesen Sie meinen Kommentar zu der Antwort, auf die Sie anspielen. Es ist eine ziemlich schlechte Antwort, da es keine Gründe gibt oder Quellen zitiert. Es widerspricht außerdem allem, was ich über das nobody-Konto und die Funktionsweise von NFS weiß: Mit " root_squashon" ordnen Sie "root" niemandem auf Remote-Systemen zu. Dies ist mehr oder weniger genau das Gegenteil von dem, was diese Antwort besagt
vidarlo

Antworten:


85

Hier können Sie Dinge ausführen, für die keine besonderen Berechtigungen erforderlich sind. Es ist normalerweise für anfällige Dienste (httpd usw.) reserviert, sodass sie im Falle eines Hacks nur minimalen Schaden am Rest des Systems verursachen.

Vergleichen Sie dies mit der Ausführung als echter Benutzer. Wenn dieser Dienst kompromittiert wird (Webserver werden gelegentlich dazu ausgenutzt, beliebigen Code auszuführen), wird er als dieser Benutzer ausgeführt und hat Zugriff auf alles, was der Benutzer hatte. In den meisten Fällen ist dies so schlimm wie root zu werden.

Sie können ein bisschen mehr über den nobody-Benutzer im Ubuntu-Wiki lesen:

So beantworten Sie Ihre Follow-ups:

Warum kann ich mit nicht auf dieses Konto zugreifen su nobody?

sudo grep nobody /etc/shadowzeigt Ihnen, dass niemand ein Passwort hat und Sie können nicht suohne ein Konto Passwort. Der sauberste Weg ist sudo su nobodystattdessen. Das wird dich in einer ziemlich trostlosen shHülle zurücklassen.

Können Sie ein bestimmtes Beispiel nennen, bei dem angegeben ist, dieses Konto zu verwenden?

Wenn für die Operationen eines Programms keine Berechtigungen erforderlich sind. Dies ist am bemerkenswertesten, wenn es keine Festplattenaktivität geben wird.

Ein reale Welt Beispiel hierfür ist memcached(eine Schlüssel-Wert - In-Memory - Cache / Datenbank / Sache), sitzt auf meinem Computer und mein Server unter dem niemandem Konto ausgeführt wird . Warum? Da es einfach keine Berechtigungen benötigt und es einem Konto zu geben, das Schreibzugriff auf Dateien hatte, wäre ein unnötiges Risiko.


Nur noch zwei Dinge, wenn Sie erklären können: 1) warum ich nicht auf dieses Konto zugreifen kann su nobodyund 2) können Sie ein bestimmtes Beispiel angeben, wann angegeben ist, dieses Konto zu verwenden?
Radu Rădeanu

@ RaduRădeanu 1) Ich vermute, das liegt daran, dass kein Kennwort festgelegt wurde. Wenn Sie suein gewöhnlicher Benutzer sind, müssen Sie das Kennwort des Zielbenutzers eingeben. Versuchen Sie es sudo -idann su nobodyüber die Root-Shell (für die kein Kennwort erforderlich ist).
ein Lebenslauf vom

2
Network File SystemZuordnungen rootzu nobodylokaler Root können nicht auf alles zugreifen, wie dies bei der Remote-Root der Fall ist.
Sylwester

1
@ RaduRădeanu Bitte beachte den Bearbeitungsverlauf. Als ich den ursprünglichen Befehl (nicht das, was da ist) getestet habe, endete dieser ursprünglich in einer Dash-Shell (/ bin / sh), aber das kann ich jetzt nicht replizieren. Ihre ursprüngliche Bearbeitung war in Ordnung. Ich war es nicht, der es geändert hat.
Oli

1
Ich dachte immer, dass nobodyNFS tatsächlich / hauptsächlich als Linux-Standardbasis verwendet .
Dgonzalez

29

In vielen Unix-Varianten ist "nobody" der herkömmliche Name eines Benutzerkontos, das keine Dateien besitzt, sich in keinen privilegierten Gruppen befindet und keine anderen Fähigkeiten als die hat, die jeder andere Benutzer besitzt.

Es ist üblich, Daemons als Niemand auszuführen, insbesondere Server, um den Schaden zu begrenzen, den ein böswilliger Benutzer erleiden kann, der die Kontrolle über sie erlangt hat. Die Nützlichkeit dieser Technik wird jedoch verringert, wenn mehr als ein Dämon auf diese Weise ausgeführt wird, da die Kontrolle über einen Dämon dann die Kontrolle über alle Dämonen bietet. Der Grund dafür ist, dass sich Prozesse, die niemandem gehören, gegenseitig Signale senden und sogar gegenseitig Fehler beheben können, sodass sie den Speicher des anderen lesen oder sogar ändern können.

Informationen stammen aus http://en.wikipedia.org/wiki/Nobody_(Benutzername) .


-1: nobodyist ausschließlich für NFS bestimmt und sollte nicht von anderen Diensten und auf keinen Fall von Systemadministratoren verwendet werden. Vielen Dank.
Sarnold

22

Der Benutzer nobody ist nur für NFS reserviert.

Die obigen Antworten sind eher falsch, da davon ausgegangen wird, dass nobodyes sich um eine "generische" anonyme Benutzer-ID handelt.

Im UNIX / Linux-Zugriffssteuerungsmodell gibt es keine anonymen / Gast-Benutzer-IDs. Dies sind schlechte Vorschläge:

  • Gemeinsame Daemons als laufen nobody, vor allem Server, um den Schaden zu begrenzen , die von einem böswilligen Benutzer die Kontrolle über sie gewonnen getan werden könnte. “ , Wegen der, der folgt: " Allerdings ist die Nützlichkeit dieser Technik reduziert , wenn mehr als ein Daemon wird so ausgeführt, weil dann die Kontrolle über einen Daemon die Kontrolle über alle anderen geben würde ".
  • " Ein Beispiel aus der Praxis ist memcached(ein Cache / eine Datenbank / ein Ding mit Schlüsselwert im Arbeitsspeicher), das auf meinem Computer und auf meinem Server unter dem nobodyKonto ausgeführt wird. Warum? Weil es einfach keine Berechtigungen benötigt und diese gibt Ein Konto, das Schreibzugriff auf Dateien hatte, wäre nur ein unnötiges Risiko. "

Der nobodyBenutzername mit der Benutzer-ID 65534 wurde für einen bestimmten Zweck erstellt und reserviert und sollte nur für diesen Zweck verwendet werden: als Platzhalter für "nicht zugeordnete" Benutzer und Benutzer-IDs in NFS-Baumexporten.

Das heißt, sofern keine Benutzer- / ID-Zuordnung für NFS-Baumexporte eingerichtet ist, werden alle Dateien im Export als Eigentum von angezeigt nobody. Damit soll verhindert werden, dass alle Benutzer auf dem importierenden System auf diese Dateien zugreifen (es sei denn, sie haben "andere" Berechtigungen), da keine von ihnen (außer root) sein kann / werden kann nobody.

Daher ist es eine sehr schlechte Idee, sie nobodyfür einen anderen Zweck zu verwenden, da der Zweck darin besteht, ein Benutzername / eine Benutzer-ID für Dateien zu sein, auf die niemand zugreifen darf.

Der Wiki-Eintrag ist auch sehr falsch.

Die UNIX / Linux-Praxis besteht darin, für jede "Anwendung" oder jeden Anwendungsbereich, der eine separate Zugriffssteuerungsdomäne benötigt, ein neues Konto zu erstellen und diese niemals nobodyaußerhalb von NFS wiederzuverwenden .


Diese Antwort zitieren keine Quellen, und widerspricht ausdrücklich mehrere der anderen Antworten, die tun Quellen zitieren. Das aktuelle Kopfgeld zeigt an, dass diese Antwort besonders gut ist. In diesem Fall sollte es einige Quellen zitieren oder eine Begründung auflisten.
Vidarlo


@ mook765 Dieser Teil ist in Ordnung. Den Absatz über NFS grok ich allerdings nicht. Zum Beispiel mit root_squashon, rootwird dem Benutzer zugeordnet nobody, so dass Dateien mit Eigentümer nobodyabsolut keinen Sinn machen würden. Darüber hinaus ist die Aussage, dass Dateien, deren Eigentümer niemand ist, für niemanden unzugänglich sein sollen, wenig sinnvoll, da Dateiberechtigungen nicht im Besitz von UNIX sind. Ich sage nicht, dass alles in der Antwort falsch ist, nur dass Elemente davon für mich wenig oder keinen Sinn ergeben :)
vidarlo

1
@vidarlo, diese Antwort schlägt nicht vor, dass Sie Dateien als Eigentümer festlegen sollten nobody. Es sagt Ihnen, dass nobodyNFS zum Zuordnen von Berechtigungen verwendet werden soll, und das ist der wichtigste Punkt für mich. Wie NFS verwendet nobodyist weniger interessant als die Tatsache , dass es nicht verwenden nobody. Vielen Dank.
Sarnold

@sarnold die antwort ist in dieser sache meiner meinung nach noch schlicht falsch. Wenn ein Benutzer die Antwort und liest man exports, ist er möglicherweise sehr verwirrt.
Vidarlo

17

Der nobodyBenutzer wird standardmäßig bei einer Neuinstallation erstellt (aktiviert auf Ubuntu Desktop 13.04).

In vielen * nix-Varianten nobodyist der herkömmliche Name eines Benutzerkontos, das keine Dateien besitzt, sich in keinen privilegierten Gruppen befindet und keine anderen Fähigkeiten als die hat, die jeder andere Benutzer besitzt ( nobodyBenutzer und Gruppe haben keinen Eintrag in der /etc/sudoersDatei). .

Es ist üblich , laufen Daemons wie nobody, vor allem Server, um den Schaden zu begrenzen , die von einem böswilligen Benutzer die Kontrolle über sie gewonnen getan werden könnte. Die Nützlichkeit dieser Technik wird jedoch verringert, wenn mehr als ein Dämon auf diese Weise ausgeführt wird, da die Kontrolle über einen Dämon dann die Kontrolle über alle Dämonen bietet. Der Grund dafür ist, dass nobodyeigene Prozesse in der Lage sind, Signale untereinander zu senden und sogar gegenseitig Fehler zu beheben, sodass sie den Speicher des jeweils anderen lesen oder sogar ändern können.

Quelle : Wikipedia - Niemand (Benutzername)


Die nobodyeigenen Prozesse können sich gegenseitig Signale senden und sich sogar gegenseitig in Linux verfolgen, was bedeutet, dass ein Prozess, der niemandem gehört, den Speicher eines anderen Prozesses, der niemandem gehört, lesen und schreiben kann.

Dies ist ein Beispieleintrag des nobodyBenutzers in der /etc/passwdDatei:

alaa@aa-lu:~$ grep nobody /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh

Wie Sie vielleicht bemerken, hat der nobodyBenutzer /bin/shals Login-Shell und /nonexistentals Home-Verzeichnis. Wie der Name schon sagt, existiert das /nonexistentVerzeichnis standardmäßig nicht.

Wenn Sie paranoid sind, können Sie die nobodyStandardshell als festlegen /usr/sbin/nologinund so die SSH-Anmeldung für den nobodyBenutzer verweigern .

Quelle : LinuxG.net - The Linux and Unix Nobody User


Diese Antwort hätte eine +1 verdient, wenn der falsche Absatz aus Wikipedia entfernt worden wäre. Vielen Dank.
Sarnold

3

nobody ist ein spezielles Benutzer- und Gruppenkonto. Da es sich um einen tatsächlichen Benutzernamen (und Gruppennamen) handelt, der von Prozessen und sogar Benutzern verwendet werden kann, ist er nicht buchstäblich niemand . Beispielsweise haben einige Apache-Konfigurationen niemanden als Benutzer / Gruppe, dem die Website-Dateien und -Verzeichnisse gehören. Das Problem tritt auf, wenn mehrere Prozesse den Benutzer nobody verwenden, z. B. NFS-Verzeichnisse und der Webserver.


0

Kleinere Korrekturen am ' Der Benutzer nobody ist nur für NFS reserviert. ' Antworten. Der nobodyBenutzer wird zu diesem Zeitpunkt auch für nichtprivilegierte Container mit Bindemounts verwendet.

Dies stammt aus systemd-nspawn, insbesondere der Mount-Option --bind:

Beachten Sie, dass, wenn diese Option in Kombination mit --private-users verwendet wird, die resultierenden Einhängepunkte dem nobody-Benutzer gehören. Dies liegt daran, dass der Mount und seine Dateien und Verzeichnisse weiterhin den relevanten Hostbenutzern und -gruppen gehören, die nicht im Container vorhanden sind, und daher unter der Platzhalter-UID 65534 (nobody) angezeigt werden. Wenn solche Bindungsbereitstellungen erstellt werden, wird empfohlen, sie mit --bind-ro = schreibgeschützt zu machen.

systemd-nspawn

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.