Sudo en tant qu'utilisateur différent et écran en cours d'exécution

167

J'ai découvert aujourd'hui que faire fonctionner screen en tant qu'utilisateur différent, ce qui me rend soudo ne fonctionnera pas!

c'est à dire

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

J'ai un script qui s'exécute en tant qu'utilisateur "moniteur". Nous l'exécutons dans une session d'écran afin de voir la sortie à l'écran. Le problème est que nous avons un certain nombre d’utilisateurs qui se connectent avec leur propre compte (par exemple, bob, james, susie, etc.), puis ils se connectent ensuite à l’utilisateur «moniteur». Leur donner accès à l'utilisateur "moniteur" est hors de question.

sudo gnu-screen

— chanceytaxi
source

13

Est-ce l'erreur que vous obtenez? "Impossible d'ouvrir votre terminal '/ dev / pts / 0' - veuillez vérifier."

— Jim

oui c'est le bon. Je comprends pourquoi cela se produit, mais existe-t-il une solution de contournement?

— luckytaxi

4

Un commentaire sur vos commandes - Je continue à voir des gens courir sudo su "user" -. Pourquoi ne pas utiliser sudo -u user -s?

— Andrew Aylett

2

@ Jim: +1 pour fournir le message d'erreur manquant.

— Dennis Williamson

1

@ Andrew La plupart des gars que je connais connaissent sudo su- je pense que c'est simplement ce à quoi les gens s'habituent (dans mon cas, c'est parce que vous n'avez pas besoin de connaître les drapeaux sudo sudo su- je ne pense pas avoir déjà lu la page de manuel sudo :)

— voretaq7

246

Essayez d’exécuter en script /dev/nulltant qu’utilisateur suavant de lancer l’écran - c’est un petit bidouillage de ghetto, mais cela devrait rendre l’écran heureux.

— voretaq7
source

5

Incidences sur la sécurité, aucune à ma connaissance (mais cela ne veut pas dire qu'il n'en existe pas :) - IIRC cela repose sur un effet secondaire de "script" ouvrant un nouveau terminal (comme l'utilisateur l'invoque) , et puisque vous envoyez la sortie du script à / dev / null, il n’ya rien à capturer. C'est aussi définitivement plus sûr que d'ajouter des utilisateurs au groupe de tty (IMHO)

— voretaq7

2

@nalply Franchement, vous ne devriez pas trouver plusieurs shells déroutant si vous êtes administrateur système Unix - cela dit, vous scriptpouvez l'utiliser pour vous lancer screen. Ensuite, il vous suffit de sortir deux fois (une fois screen, une fois su). (Ceci est quelque chose que la scriptpage de manuel peut clarifier pour vous, si vous prenez le temps de le lire ...)

— voretaq7

10

Ou tout simplement courir sudo -u bob script -q -c 'screen -dr myscreen' /dev/null. Il ne vous reste alors qu’un seul terminal à quitter / déconnecter.

— Andy Shulman

4

Merci, cela m'a sauvé. Mais pourquoi cela règle-t-il cela? D'après ce que j'ai compris, tout est imprimé, de la sortie standard à ... nulle part. Et cela corrige en quelque sorte l'écran.

— sudo

3

@sudo Afin de faire sa chose scriptouvre son propre périphérique tty, appartenant à l'utilisateur qui l'a exécuté (regardez dedans /devet vous le verrez apparaître après que vous ayez exécuté script). screenpuis saisit ce périphérique tty (qui appartient à l'utilisateur qui l'exécute, de screensorte qu'il n'a aucun problème à y accéder). C'est un travail de piratage total, mais cela fonctionne. En regardant certaines de mes machines, il semble que les nouvelles versions de screen semblent installer setuid-root, ce qui fonctionne également, mais signifie que vous avez un autre fichier binaire setuid-root flottant, ce qui rend certaines personnes mal à l'aise.

— voretaq7

33

J'utilise une fonction de wrapper screenpour le ou les utilisateurs auxquels je suis sudo suassocié. Voici la fonction d'emballage que j'ai ajoutée aux utilisateurs ~/.bashrc:

écran de fonction () {
  / usr / bin / script -q -c "/ usr / bin / screen $ {*}" / dev / null
}

Cela me permet d’utiliser toutes les options et tous les paramètres screenque je souhaiterais peut-être utiliser. Je songe à mettre cette fonction à l'échelle du système.

— steviethecat
source

1

Fonctionne parfaitement. Pour ceux qui souhaitent utiliser l'ensemble du système, je recommande de l'ajouter à /etc/bash.bashrc - fonctionne pour tous les utilisateurs.

— Someguy123

2

Cela ne citera pas les arguments à filtrer correctement, sinon une bonne solution.

— augurar

7

En supposant qu'ils soient SSH dans l'hôte de toute façon, vous pouvez ajouter les clés publiques ssh pour chaque utilisateur ayant besoin d'accéder au compte du moniteur dans le fichier ~ monitor / .ssh / allowed_keys. Ensuite, sur la machine distante de chaque utilisateur, ils peuvent exécuter

ssh -t monitor@remote.machine screen -RD

— Alex
source

Ceci est une autre bonne approche - vous auriez à spécifier des commandes forcées dans le fichier de clés autorisées bien (note de luckytaxi "en leur donnant accès à l'utilisateur 'moniteur' est hors de question" note ci-dessus - les commandes forcées pourraient les limiter à attachant la session d'écran)

— voretaq7

2

Je ne savais pas trop comment aborder cette question dans ma réponse, car il avait déclaré: "leur donner accès ... est hors de question", mais a également déclaré: "... ils se joignent à l'utilisateur" de moniteur "". Mais je suis d’accord, le fait de forcer la restriction de commande dans la catégorie allowed_keys devrait s’occuper de cela.

— Alex

7

En supposant que nous parlons de cette erreur:

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

Voici un one-liner (pourrait être utilisé comme "alias gobob", par exemple):

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

Explication:

Cela va démarrer un shell (comme login shell) en tant qu'utilisateur bob. L'utilisateur bob commence script, il est dit d'invoquer un bash (peut être un tiret ou ksh ...) et une copie de la session est jetée.

— basic6
source

0

Il faudrait probablement modifier les autorisations sur le périphérique en question ou ajouter un moniteur à un groupe autorisé à lire ce périphérique, ce serait ma première tendance. Mais il vous faudra peser les implications en termes de sécurité.

— Bart Silverstrim
source

0

Vous dites que vous faites:

sudo su "monitor" -

Je me pose des questions sur le tiret de fuite. Je fais habituellement:

sudo su - username

Le tiret (selon la page de manuel su) indique à su de "transformer le shell en shell de connexion". Cela signifie que tous les scripts de démarrage habituels du shell seront créés à la source et que les éléments tels que PATH et HOME seront correctement définis.

— Doug Harris
source

3

Nan. sudo su - usernameet sudo su username -faire la même chose.

— Tim Ludwinski

-4

Je viens de frapper ce problème. Résolu avec chmod +rw $(tty)avant de lancer sudo. Le problème avec cette solution est que tout le monde peut se connecter et surveiller votre terminal par la suite.

— Amos Shapira
source

2

Cela semble être une excellente solution.

— Evan Carroll

10

@EvanCarroll C'est une excellente solution, à l'exception de la partie qui donne au monde entier un accès en lecture et en écriture à son terminal. Juste un problème de sécurité mineur - Aucun programme ne s’y intéresserait, à l’exception de tout ce qui vérifie la sécurité du terminal avant d’accepter des mots de passe ( gpgpar exemple). Et sûrement, il ne sera jamais sur un système avec des utilisateurs malveillants qui surveilleraient les ttymots de passe et les reniflent ...

— voretaq7

Soyez averti : n'essayez jamais cela à la maison! c'est dangereux!!!

— Ruizpauker