Pourquoi est-ce que «l'écran se termine» sans root?

J'ai installé l'écran sur Fedora 19. Lorsque je teste la commande en tant que root à distance via SSH, cela fonctionne parfaitement. Par exemple, si j'entre screenun nouvel émulateur de terminal est démarré et attend les commandes. Je peux le détacher, etc. Cependant, lorsque j'essaie de faire de même une fois que je suis connecté à distance via SSH en tant qu'utilisateur standard, la commande se termine immédiatement. Le seul message que je vois est [screen is terminating].

Est-ce que quelqu'un a déjà eu ce problème? Est-ce lié à de mauvaises autorisations?

Mise à jour:

$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/var/run/utmp", O_RDONLY)         = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/var/run/screen", {st_mode=S_IFDIR|0775, st_size=60, ...}) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++

J'ai essayé de changer les autorisations en 777 mais quand j'exécute screen, j'obtiens:

Le répertoire '/ var / run / screen' doit avoir le mode 775.

Par conséquent, j'ai annulé mes modifications.

Le basculement entre "doit avoir le mode 777" et "doit avoir le mode 775" est provoqué par strace.

screenest généralement un programme setuid ou setgid. Il obtient des privilèges supplémentaires lors de son exécution, qui est utilisé pour créer des fichiers socket et / ou modifier utmp.

Lorsqu'un processus est tracé, setuid et setgid sont désactivés. Le processus de suivi, contrôlé par l'utilisateur le moins privilégié, peut prendre le relais du processus tracé, il doit donc s'exécuter sans ses privilèges supplémentaires pour éviter de donner trop de puissance à l'utilisateur d'origine.

screen détecte s'il est exécuté avec les privilèges setuid, privilèges setgid ou aucun, et ajuste son attente des autorisations de répertoire en conséquence.

Cela crée donc une classe de problèmes qui ne peuvent pas être facilement débogués strace.

Mais si vous êtes root, il existe une solution! Si le processus de suivi s'exécute en tant que root, le processus tracé peut alors gagner des privilèges normalement. Voici donc ce que vous faites:

1. Ouvrir 2 nouveaux terminaux
2. Dans le premier terminal, connectez-vous à la machine distante en tant que root
3. Dans le deuxième terminal, connectez-vous à la machine distante en tant qu'utilisateur normal
4. Utilisez pspour obtenir le PID du processus shell de l'utilisateur normal dans le deuxième terminal
5. Dans le premier terminal, exécutez strace -f -p SHELLPID
6. Dans le deuxième terminal, exécutez l'écran et regardez-le échouer
7. Dans le premier terminal, vous avez maintenant le journal d'étape dont vous avez besoin pour découvrir ce qui ne va vraiment pas.

L'addition clé à la stracecommande est l' -foption, qui lui dit de tracer les processus enfants. Vous en avez besoin pour tracer l'écran qui sera un enfant du processus shell avec lequel vous avez spécifié -p.

J'aime aussi utiliser -ffet spécifier un fichier de sortie avec -o, comme dans

strace -ff -o /tmp/screentrace -p SHELLPID

ce qui créera un fichier de sortie distinct pour chaque processus enfant. Ensuite, vous les lisez avec less /tmp/screentrace*et le résultat est généralement plus propre que ce que vous obtenez en utilisant un seul -f.

MISE À JOUR

Maintenant que j'ai vu la sortie strace, je ne sais pas exactement ce qui s'est passé, mais cette ligne est la chose la plus surprenante dans la trace:

chown("/dev/pts/2", 1002, 5)            = -1 EPERM (Operation not permitted)

Quelques lignes plus tôt, il a créé un pty, qui s'est révélé TIOCGPTNêtre le numéro 2.

open("/dev/ptmx", O_RDWR)               = 5
...
ioctl(5, TIOCGPTN, [2])                 = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0

Mais il n'a pas pu le montrer. Je ne sais pas pourquoi ce chown échouerait, mais l'échec du chown donne une raison plausible pour laquelle l'écran a abandonné. Vous pouvez obtenir un peu plus d'informations en ajoutant -vaux options de strace et en regardant stataprès TIOCGPTNpour voir à qui appartient l' /dev/pts/entrée.

L'une des raisons possibles de ce bogue - des politiques selinux incorrectes, mais selon redhat bugtracker, ces erreurs ont été corrigées dans fedora 17/18.

Comme solution de contournement, vous pouvez changer la variable SCREENDIRen vous ~/.bashrcen quelque chose comme $HOME/.screen.

Quand j'ai rencontré ce message d'erreur. J'ai dû ajuster mes autorisations avec les éléments suivants:

chmod 2775 /usr/bin/screen

Et cela a résolu le problème pour moi. Le 2 est très important pour les autorisations d'accès correctes.

Vous devriez en savoir plus sur SUID, SGID, Sticky Bit, ACL et comment ils affectent l'accès.

La commande d'écran était déjà en cours d'exécution. Je l'ai donc terminée et retapé la commande. Oui, ce n'est pas une assez bonne résolution comme les autres, mais cela prend moins de temps.

Juste ps et trouvez le pid, tuez le PID et continuez avec la commande de retouche d'écran.

Si vous exécutez plusieurs commandes d'écran, assurez-vous de terminer le processus correct associé à votre terminal.

J'ai trouvé ce problème résolu après avoir commenté la ligne suivante dans / etc / fstab et redémarré:

devpts         /dev/pts        devpts  defaults        0       0

Assurez-vous qu'aucun autre screenn'utilise cet appareil

Cela peut être réalisé avec /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

Et puis tuez ce processus si tel est le cas.

Pour une raison quelconque, dans cette condition, sudo screenpeut toujours accéder à l'appareil, mais alors cette connexion manquera de caractères, qui sont consommés par l'autre screen.

Assurez-vous que l'utilisateur a l'autorisation de lire et d'écrire sur le fichier

Par exemple, sur Ubuntu, vous souhaitez ajouter l'utilisateur au dialoutgroupe: /ubuntu//a/133244/52975

J'ai exactement le même problème et une sortie strace assez similaire.

Cela l'a corrigé:

sudo chmod u+s /usr/bin/screen
sudo chmod 755 /var/run/screen

crédits: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/