Wird der ausführbare Berechtigungsmodus S für alles verwendet?

Wenn Sie das Setuid-Bit für die Berechtigung einer Datei hinzufügen, für die Sie die Ausführungsberechtigung haben, ändert es das x zu einem s bedeutet, dass, wenn Sie diese Datei ausführen, sie als Eigentümer der Datei ausgeführt wird und nicht als die Person, die sie tatsächlich ausführt.

Aber ich habe auch bemerkt, dass wenn Sie s hinzufügen Berechtigung, aber entferne x Berechtigung ändert es sich in ein S in der Berechtigungsliste. Irgendwie würde dies bedeuten, dass es nicht ausgeführt werden könnte, aber es würde gleichzeitig als Eigentümer ausgeführt werden, wenn es ausgeführt werden könnte? Stimmt das?

Verstehe ich diese Erlaubnis falsch? Was wird es verwendet? Was bedeutet das?

Akzeptierte Antwort:

Alle vier Kombinationen existieren und sind sinnvoll.

"Kann der tatsächliche Besitzer dieser Datei sie ausführen?" und „Wer wird das System so tun, als ob er diese Datei ausführt?“ sind zwei getrennte Fragen. Alle vier Kombinationen sind möglich und sinnvoll.

Berechtigungsstrings, die von ls -l angezeigt werden oder stat -c %A show, an der Ausführungsposition des Besitzers (d. h. anstelle von ? in ---?------ ), vier verschiedene Zeichen, eines für jede Kombination:

1. - bedeutet, dass der Eigentümer nicht kann Führen Sie die Datei aus, und wenn ein Nicht-Eigentümer sie ausführt, wird sie als dieser andere Benutzer ausgeführt .
2. x bedeutet, dass der Besitzer kann Führen Sie die Datei aus, und wenn ein Nicht-Eigentümer sie ausführt, wird sie als dieser andere Benutzer ausgeführt .
3. S bedeutet, dass der Eigentümer nicht kann Führen Sie die Datei aus, und wenn ein Nicht-Eigentümer sie ausführt, wird sie stattdessen als der Eigentümer ausgeführt .
4. s bedeutet, dass der Besitzer kann Führen Sie die Datei aus, und wenn ein Nicht-Eigentümer sie ausführt, wird sie stattdessen als der Eigentümer ausgeführt .

Das Setuid-Bit und die Ausführungsbits sind getrennte Bits, und der Modus String ist wirklich nur eine bequeme Möglichkeit, die Berechtigungsbits anzuzeigen, einschließlich dieser. Eine andere Möglichkeit, darüber nachzudenken, ist:

• x oder s bedeutet, dass das Ausführungsbit gesetzt ist. - oder S bedeutet, dass dies nicht der Fall ist.
• s oder S bedeutet, dass das setuid-Bit gesetzt ist. - oder x bedeutet, dass dies nicht der Fall ist.

In ähnlicher Weise kann eine Gruppe Ausführungsberechtigungen für eine Datei haben oder nicht, und wenn sie ausgeführt wird, kann sie mit einer anderen Gruppenidentität als der des Benutzers ausgeführt werden oder nicht, der sie ausführt. Damit eine Datei mit der Gruppenidentität ihres Gruppeneigentümers und nicht mit der des Benutzers ausgeführt wird, der sie ausführt, würden Sie das setgid-Bit (------s--- oder ------S--- ).

S stellt kein separates Modusbit dar. Es ist einfach eine Möglichkeit, anzuzeigen, dass das setuid- (oder setgid-) Bit gesetzt ist, aber das entsprechende ausführbare Bit nicht gesetzt ist.

$ touch foo
$ chmod u+S foo
chmod: invalid mode: ‘u+S’
Try 'chmod --help' for more information.

Sie können die Bits selbst untersuchen.

Um zu sehen, dass es sich um separate Bits handelt, verwenden Sie den %a Formatbezeichner für stat statt %A . Der Einfachheit halber habe ich alle anderen Modusbits deaktiviert.

$ touch a b c d
$ chmod u=,g=,o= a
$ chmod u=x,g=,o= b
$ chmod u=s,g=,o= c
$ chmod u=xs,g=,o= d
$ stat -c '%A %n' a b c d
---------- a
---x------ b
---S------ c
---s------ d
$ stat -c '%04a %n' a b c d
0000 a
0100 b
4000 c
4100 d

Das macht es klar ... wenn Sie mit Oktal vertraut sind. Wenn Sie es in Binärform sehen möchten (sie sind immerhin Bits) können Sie die Darstellungen umwandeln:

$ stat -c '%a %n' a b c d | perl -pe 's/\d+/sprintf("%012b", oct($&))/e'
000000000000 a
000001000000 b
100000000000 c
100001000000 d

Setuid setzt die effektive Benutzer-ID, nicht die echte Benutzer-ID.

Execute-Bits steuern, ob ein Versuch, eine Datei auszuführen, erfolgreich sein kann oder nicht, während setuid/setgid-Bits steuern, unter welcher Identität der neue Prozess ausgeführt wird, wenn er erstellt werden darf. An der Kombination der Berechtigungen S ist also nichts Widersprüchliches oder Überraschendes steht für (-x,+s ). Dies wäre selbst dann der Fall, wenn eine ausführbare Datei, die als ihr Besitzer ausgeführt wird, weil ihr Besitzer sie wirklich ausgeführt hat, genauso funktioniert wie eine ausführbare Datei, die als ihr Besitzer ausgeführt wird, weil jemand sie ausgeführt hat, aber sie war setuid. Aber so funktioniert es nicht.

Der Kernel verwendet mehr als eine Nummer, um die Benutzeridentität eines laufenden Prozesses zu verfolgen. Eine dieser Nummern ist die UID und eine andere die EUID. Weitere Informationen finden Sie in diesem Artikel. Das Setuid-Bit bewirkt, dass die EUID (effektive Benutzer-ID) geändert wird, aber die UID (reale Benutzer-ID) bleibt gleich. Eine Verwendung davon ist, dass Signale zwischen Prozessen ausgetauscht werden können, die eine UID teilen, aber unterschiedliche EUIDs haben, aber eine andere ist, dass es einem Programm erlaubt, dessen setuid-Bit gesetzt ist, zu überprüfen, wer es ausgeführt hat .

Beispiel:passwd muss setuid sein, da nur root Einträge in der Passwortdatenbank ändern kann:

$ ls -l "$(command -v passwd)"
-rwsr-xr-x 1 root root 54256 May 16 19:37 /usr/bin/passwd

-rwsr-xr-x hat r-x am Ende für andere . Aufgrund des x , sogar Benutzer, die nicht root oder in der root-Gruppe sind, können passwd ausführen . Und es hat rws am Anfang, für Eigentümer . Aufgrund der s , wird das Programm als root ausgeführt, auch wenn es von Nicht-Eigentümern ausgeführt wird. Aber wenn Sie passwd ausführen Sie selbst, es setzt Ihr Passwort zurück, nicht das von root.

passwd ist fähig keine Änderung an der Datenbank mit Benutzern und Passwörtern vorzunehmen, da sie mit der effektiven Benutzer-ID von root ausgeführt wird. Aber es ist so konzipiert, dass es sich weigert, das Passwort von irgendjemandem außer dem Benutzer zu ändern, der es ausgeführt hat – außer wenn dieser Benutzer root ist – weil es seine echte Benutzer-ID überprüft.

Verwandte:gdomap und wofür wird es verwendet?

Dies ist der typische Anwendungsfall der ausführbaren setuid-Datei:Erstellen einer Schnittstelle, die es einem Benutzer ermöglicht, Aktionen zu veranlassen, die von einem anderen ausgeführt werden, auf eine begrenzte Weise, die durch den Code der ausführbaren setuid-Datei überprüft wird. Daher ist es nur sicher, das Setuid-Bit (oder das Setgid-Bit) in einem Programm zu setzen, das entworfen wird um diese Berechtigungen zu haben.

Dies ist das andere Puzzleteil, um zu verstehen, warum die Berechtigungen S Bedeutungen sind kein Rätsel:die Macht, die das Setuid-Bit verleiht, nicht das Gleiche erreichen, als würde man das Programm tatsächlich als Eigentümer ausführen , auch wenn das Programm ausgeführt werden darf.

Überprüfung von UID und EUID mit einer Kopie von id zeigt, wie setuid funktioniert.

Okay, gut, ich werde das setuid-Bit auf einer ausführbaren Datei setzen, die nicht dafür ausgelegt ist, um zu zeigen, wie die echten und effektiven Benutzer-IDs beeinflusst werden.

• Die ausführbare Datei ist eine Kopie der id Programm, das unter anderem seine echten und effektiven Benutzer-IDs meldet. Obwohl dieses Programm nicht dafür ausgelegt ist, setuid zu sein, ist es auch nicht dafür ausgelegt, irgendetwas zu ändern – außer durch die Ausgabe von Ausgaben –, also ist dies einigermaßen sicher. Aber Sie sollten es danach trotzdem löschen. (Ihre Kopie. Nicht das Original.)
• Wir verwenden eine Kopie, nicht Ändern der Berechtigungen für das Original. Du nicht müssen sudo verwenden oder führen Sie eine beliebige Aktion als Root aus.
• Um es als ein anderer Benutzer auszuführen, benötigen Sie ein zweites Benutzerkonto, aber Sie können su verwenden Aktionen als dass auszuführen Benutzer. (Standardmäßig ist die root Ihr Konto erlaubt Ihnen nicht, sich mit einem Passwort anzumelden, also wenn Sie einen Fehler machen und su ausführen ohne den Benutzernamen anzugeben, zu dem Sie wechseln möchten, werden Sie nicht versehentlich stattdessen root, es sei denn, Sie haben auch Root-Logins aktiviert. Wenn Sie wirklich sudo -u user statt su user -c , aber dann kannst du es.)

Mein Hauptbenutzerkonto heißt ek und mein zweites Konto ist ek2 . Es ist in Ordnung, wenn Ihre anders sind. Zuerst als ek , ich kopiere id in das aktuelle Verzeichnis (das sich irgendwo in meinem Home-Verzeichnis befindet):

$ type -a id
id is /usr/bin/id
$ cp /usr/bin/id .

Die Kopie hat das Eigentum des Nicht-Root-Benutzers, der sie kopiert hat, aber die ursprünglichen Berechtigungen:

$ ls -l id /usr/bin/id
-rwxr-xr-x 1 ek   ek   39760 Oct  5 11:23 id
-rwxr-xr-x 1 root root 39760 Mar  2  2017 /usr/bin/id

Übergeben von -n zu id zeigt Namen statt ID-Nummern, -u zeigt den Benutzer (und keine anderen Informationen wie Gruppen) und -r bewirkt, dass die echte Benutzer-ID angezeigt wird. Ohne -r , -u zeigt die effektive Benutzer-ID. Dieses Verhalten gilt vollständig für die Kopie von id Ich habe gerade gemacht.

Wenn ich es als Ersatzbenutzer ausführe, werden sowohl die echten als auch die effektiven Benutzer-IDs geändert. Dies ist Teil von su und sudo geschrieben und ist kein bloßes Ergebnis von su selbst ist setuid root, obwohl es so ist. (Deshalb habe ich passwd verwendet als Beispiel für eine typische ausführbare setuid-Datei anstelle von su oder sudo .) Dies ist unsere Basis, um diese id zu sehen im aktuellen Verzeichnis funktioniert wie erwartet:

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek2
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Jetzt erstelle ich diese lokale Kopie von id setuid:

$ chmod u+s id
$ ls -l id
-rwsr-xr-x 1 ek ek 39760 Oct  5 11:42 id

Wenn ich es jetzt ausführe, ist seine echte Benutzer-ID immer noch die des Benutzers, der es ausgeführt hat, während seine effektive Benutzer-ID die von ek ist auch wenn ek2 läuft es:

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Jetzt entziehe ich dem Eigentümer die Ausführungsberechtigungen, überlasse sie aber allen anderen:

$ chmod u-x id
$ ls -l id
-rwSr-xr-x 1 ek ek 39760 Oct  5 11:42 id

ek2 kann es immer noch wie mit ek ausführen ’s effektive Benutzer-ID, obwohl ek kann es nicht ausführen:

$ ./id -nu                # ek runs id, displaying the effective user
-bash: ./id: Permission denied
$ ./id -nur               # ek runs id, displaying the real user
-bash: ./id: Permission denied
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Aber wie gezeigt, hat dies nicht das gleiche Ergebnis wie ek erzeugt es tatsächlich laufen. ek2 kann nicht wirklich was ek könnte tun, wenn ek durften das Programm ausführen, es sei denn, das Programm erlaubt es.

Verwandte:Kann Ubuntu auf Acer Aspire ES17 nicht booten?

(Danach habe ich rm id ausgeführt um die Datei zu entfernen, damit keine unnötige ausführbare setuid-Datei in meinem Home-Verzeichnis herumliegt. Oder Sie könnten einfach das Setuid-Bit mit chmod -s id zurücksetzen .)