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


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

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, c’est que nous avons un certain nombre d’utilisateurs qui se connectent avec leur propre compte (par exemple, bob, james, susie, etc.), puis s’installent ensuite dans l’utilisateur "moniteur". Leur donner accès à l'utilisateur "moniteur" est hors de question.


150
2018-02-25 15:07


origine


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
Un commentaire sur vos commandes - Je continue à voir des gens courir sudo su "user" -. Pourquoi ne pas utiliser sudo -u user -s? - Andrew Aylett
@ Jim: +1 pour fournir le message d'erreur manquant. - Dennis Williamson
@ Andrew La plupart des gars que je connais font sudo su - Je pense que c'est juste ce à quoi les gens s'habituent (dans mon cas c'est parce que vous n'avez pas besoin de connaître les drapeaux sudo pour sudo su - Je ne pense pas avoir déjà lu la page de manuel sudo :) - voretaq7


Réponses:


Essayez de courir script /dev/null en tant qu'utilisateur vous su avant de lancer l’écran - c’est un petit bidouillage du ghetto, mais cela devrait rendre l’écran heureux.


220
2018-02-25 16:46



Incidences sur la sécurité, aucune à ma connaissance (mais cela ne veut pas dire qu'il n'y en a pas :) - IIRC cela repose sur un effet secondaire du "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 tty (IMHO) - voretaq7
@nalply Franchement, vous ne devriez pas trouver plusieurs shells déroutant si vous êtes un administrateur système Unix - cela dit, script peut être utilisé pour lancer screen. Ensuite, il vous suffit de sortir deux fois (une fois pour screen, une fois pour su). (C'est quelque chose que le script page de manuel peut clarifier pour vous, si vous prenez le temps de le lire ...) - voretaq7
Ou juste 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
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
@sudo Pour faire sa chose script ouvre son propre périphérique tty, appartenant à l'utilisateur qui l'a exécuté (regardez dans /dev et vous le verrez apparaître après avoir couru script). screen puis saisit ce périphérique tty (qui appartient à l'utilisateur en cours d'exécution screen donc il n’a aucun mal à y accéder). C'est un travail de piratage total, mais cela fonctionne. En regardant certaines de mes machines, il apparaît 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


J'utilise une fonction wrapper autour de screen pour le (s) utilisateur (s) que je sudo su à. C’est la fonction de wrapper 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 pour screen que je pourrais vouloir utiliser. J'envisage de mettre cette fonction à l'échelle du système.


32
2017-08-13 13:45



Marche 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
Cela ne citera pas les arguments à filtrer correctement, sinon une bonne solution. - augurar


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 / registered_keys. Ensuite, sur la machine distante de chaque utilisateur, ils peuvent exécuter

ssh -t monitor@remote.machine screen -RD


7
2018-02-25 16:52



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 à attacher la session d'écran) - voretaq7
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" moniteur "". Mais je suis d’accord, le fait de forcer la restriction de commande dans la commande allowed_keys devrait s’occuper de cela. - Alex


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 shell de connexion) en tant qu'utilisateur bob. L'utilisateur bob commence script, qui est invoqué pour invoquer un bash (peut être dash ou ksh ...) et une copie de la session est jetée.


6
2018-02-22 08:36





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é.


0
2018-02-25 15:51





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.


0
2018-02-25 18:44



Nan. sudo su - username et sudo su username - faire la même chose. - Tim Ludwinski


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.


-2
2018-06-22 02:09



Cela semble être une excellente solution. - Evan Carroll
@EvanCarroll C'est une excellente solution, sauf la partie où elle donne Le monde entier accès en lecture et en écriture à son terminal. Seul 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 (gpg par exemple). Et sûrement, il ne sera jamais sur un système avec des utilisateurs malveillants qui regarderaient la tty et renifler les mots de passe ... - voretaq7
Être averti: n'essayez jamais cela à la maison! c'est dangereux!!! - ruizpauker