Sudo als anderer Benutzer und laufender Bildschirm

167

Habe heute herausgefunden, dass das Ausführen von screen als ein anderer Benutzer, in den ich sudo, nicht funktioniert!

dh

ssh bob@server         # ssh into server as bob
sudo su "monitor" -
screen                 # fails: Cannot open your terminal '/dev/pts/0'

Ich habe ein Skript, das als "Monitor" -Benutzer ausgeführt wird. Wir führen es in einer Bildschirmsitzung aus, um die Ausgabe auf dem Bildschirm zu sehen. Das Problem ist, dass wir eine Reihe von Benutzern haben, die sich mit ihrem eigenen Konto anmelden (z. B. Bob, James, Susie usw.) und dann in den "Monitor" -Benutzer wechseln. Es kommt nicht in Frage, ihnen Zugriff auf den "Monitor" -Benutzer zu gewähren.

sudo gnu-screen

— luckytaxi
quelle

13

Ist das der Fehler, den Sie bekommen? "Das Terminal '/ dev / pts / 0' kann nicht geöffnet werden - bitte überprüfen."

— Jim

yep das ist der eine. Ich verstehe, warum es passiert, aber gibt es eine Problemumgehung?

— luckytaxi

4

Ein Kommentar zu Ihren Befehlen - ich sehe immer wieder Leute rennen sudo su "user" -. Warum nicht benutzen sudo -u user -s?

— Andrew Aylett

2

@Jim: +1 für das Liefern der fehlenden Fehlermeldung.

— Dennis Williamson

1

@ Andrew Die meisten Leute, die ich kenne sudo su- ich denke, es ist genau das, woran sich die Leute gewöhnen (in meinem Fall, weil Sie keine Sudo-Flags kennen müssen sudo su- ich glaube nicht, dass ich jemals die Sudo-Manpage gelesen habe :)

— Voretaq7

245

Versuchen script /dev/nullSie su, vor dem Start von screen als der Benutzer auszuführen, den Sie möchten - es ist ein kleiner Ghetto-Hack, aber es sollte den Bildschirm glücklich machen.

— voretaq7
quelle

5

Betreff: Auswirkungen auf die Sicherheit, keine, die mir bekannt sind (aber das heißt nicht, dass es keine gibt :) - IIRC beruht auf dem Nebeneffekt von "Skript" beim Öffnen eines neuen Endgeräts (wenn der Benutzer es aufruft) , und da Sie die Ausgabe des Skripts an / dev / null senden, gibt es nichts zu erfassen. Es ist auch auf jeden Fall sicherer, als Benutzer zur tty-Gruppe (IMHO)

— hinzuzufügen

2

@nalply Ehrlich gesagt, sollten Sie nicht mehrere Shells verwirren, wenn Sie ein Unix-Systemadministrator sind - das heißt, scriptkann zum Starten verwendet werden screen. Dann müssen Sie nur noch zweimal (einmal für screen, einmal für su) beenden. (Dies ist etwas, das die scriptManpage für Sie klären kann, wenn Sie sich die Zeit nehmen, es zu lesen ...)

— voretaq7

10

Oder einfach rennen sudo -u bob script -q -c 'screen -dr myscreen' /dev/null. Dann haben Sie nur noch ein Terminal zum Verlassen / Trennen.

— Andy Shulman

4

Danke, das hat mich gerettet. Aber warum behebt dies das Problem? Soweit ich weiß, druckt es alles von Standard bis ... nirgendwo. Und das repariert irgendwie den Bildschirm.

— Sudo

3

@sudo Damit dies funktioniert, scriptwird ein eigenes tty-Gerät geöffnet, das dem Benutzer gehört, der es /devausgeführt hat script. screenDann schnappt er sich das tty-Gerät (das dem laufenden Benutzer gehört, screendamit er problemlos darauf zugreifen kann). Es ist ein totaler Hack-Job, aber es funktioniert. Wenn ich mir einige meiner Computer anschaue, scheint es, als würden neue Versionen von screen setuid-root installieren, was ebenfalls funktioniert, aber bedeutet, dass Sie eine andere setuid-root-Binärdatei haben, die herumschwebt, was einige Leute zu Recht unwohl macht.

— Voretaq7

33

Ich verwende eine Wrapper-Funktion screenfür die Benutzer, die ich verwenden sudo sumöchte. Dies ist die Wrapper-Funktion, die ich den Benutzern hinzugefügt habe ~/.bashrc:

Funktionsbildschirm () {
  / usr / bin / script -q -c "/ usr / bin / screen $ {*}" / dev / null
}

Dadurch kann ich alle Optionen und Parameter verwenden screen, die ich verwenden möchte. Ich denke darüber nach, diese Funktion systemweit einzusetzen.

— Steviethecat
quelle

1

Funktioniert perfekt. Für diejenigen, die dies systemweit wollen, empfehle ich, dies zu /etc/bash.bashrc hinzuzufügen - funktioniert für alle Benutzer.

— Someguy123

2

Hierdurch werden keine Argumente für die korrekte Anzeige angegeben, da dies ansonsten eine gute Lösung ist.

— 9.

7

Angenommen, sie sind sowieso SSH-fähig auf dem Host, könnten Sie die öffentlichen SSH-Schlüssel für jeden Benutzer, der Zugriff auf das Monitorkonto benötigt, in der Datei ~ monitor / .ssh / authorized_keys hinzufügen. Dann können sie auf dem Remote-Computer jedes Benutzers ausgeführt werden

ssh -t monitor@remote.machine screen -RD

— Alex
quelle

Dies ist ein weiterer guter Ansatz - Sie müssten allerdings erzwungene Befehle in der Datei mit den autorisierten Schlüsseln angeben (laut luckytaxi ist das Erteilen des Zugriffs auf den 'Monitor'-Benutzer ausgeschlossen) Anhängen der Bildschirmsitzung)

— voretaq7

2

Ich war mir nicht sicher, wie ich das in meiner Antwort angehen sollte, weil er sagte, "ihnen Zugang zu gewähren ... kommt nicht in Frage", sondern auch "... sie stürzen sich in den 'Monitor'-Benutzer". Aber ich bin damit einverstanden, dass das Erzwingen einer Befehlsbeschränkung in den authorized_keys dafür sorgen sollte.

— Alex

7

Angenommen, wir sprechen über diesen Fehler:

$ sudo su - bob
$ screen
Cannot open your terminal '/dev/pts/5' - please check.

Hier ist ein Einzeiler (könnte zum Beispiel als "Alias Gobob" verwendet werden):

sudo su - bob -c "script -c bash /dev/null"'

Erläuterung:

Dies startet eine Shell (wie Login-Shell) als Benutzer bob. Der Benutzer bob wird gestartet script, der angewiesen wird, eine Bash aufzurufen (kann ein Bindestrich oder ein ksh sein ...), und eine Kopie der Sitzung wird verworfen.

— basic6
quelle

0

Möglicherweise müssten die Berechtigungen für das betreffende Gerät geändert oder ein Monitor zu einer Gruppe hinzugefügt werden, die über die Berechtigung zum Lesen dieses Geräts verfügt. Dies wäre meine erste Neigung. Aber Sie müssten die Auswirkungen auf die Sicherheit abwägen.

— Bart Silverstrim
quelle

0

Sie sagen, Sie tun:

sudo su "monitor" -

Ich wundere mich über den nachlaufenden Gedankenstrich. Normalerweise mache ich:

sudo su - username

Der Bindestrich (laut Manpage su) weist su an, "die Shell zu einer Login-Shell zu machen". Dies bedeutet, dass alle üblichen Shell-Startskripte erzeugt und Dinge wie PATH und HOME korrekt eingestellt werden.

— Doug Harris
quelle

3

Nee. sudo su - usernameund sudo su username -mache dasselbe.

— Tim Ludwinski

-4

Ich bin gerade auf dieses Problem gestoßen. Behebung mit chmod +rw $(tty)vor dem Ausführen von sudo. Das Problem bei dieser Lösung besteht darin, dass sich danach jeder mit Ihrem Terminal verbinden und nachschauen kann.

— Amos Shapira
quelle

2

Klingt nach einer großartigen Lösung.

— Evan Carroll

10

@EvanCarroll Es ist eine großartige Lösung, mit Ausnahme des Teils, in dem die ganze Welt Lese- und Schreibzugriff auf sein Terminal hat. Nur ein kleines Sicherheitsproblem - Kein Programm würde sich darum kümmern, außer natürlich irgendetwas, das die Terminalsicherheit prüft, bevor Passwörter akzeptiert werden ( gpgzum Beispiel). Und sicher wird er nie auf einem System mit böswilligen Benutzern sein, die die ttyPasswörter beobachten und daran

— riechen

Seien Sie gewarnt : Versuchen Sie dies niemals zu Hause! das ist gefährlich!!!

— Ruizpauker