Perché visualizzo "lo schermo sta terminando" senza root?

Ho installato lo schermo su Fedora 19. Quando collaudo il comando come root da remoto tramite SSH, funziona perfettamente. Ad esempio, se inserisco screenun nuovo emulatore di terminale viene avviato e attende i comandi. Posso staccarlo, ecc. Tuttavia, quando provo a fare lo stesso dopo aver effettuato l'accesso remoto tramite SSH come utente standard, il comando termina immediatamente. L'unico messaggio che vedo è [screen is terminating].

Qualcuno ha già avuto questo problema? È legato a permessi errati?

Aggiornare:

$ 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 +++

Ho provato a cambiare le autorizzazioni a 777 ma poi quando eseguo screen, ottengo:

La directory '/ var / run / screen' deve avere la modalità 775.

Pertanto, ho ripristinato le mie modifiche.

Il Flip-flop tra "deve avere la modalità 777" e "deve avere la modalità 775" è causato da strace.

screenè di solito un programma setuid o setgid. Ottiene i privilegi extra quando viene eseguito, che viene utilizzato per creare file socket e / o modificare utmp.

Quando viene tracciato un processo, setuid e setgid sono disabilitati. Il processo di tracciamento, controllato dall'utente meno privilegiato, può subentrare al processo di tracciamento, quindi deve essere eseguito senza i suoi privilegi extra per evitare di dare troppa potenza all'utente originale.

screen rileva se viene eseguito con privilegi setuid, privilegi setgid o nessuno dei due e regola di conseguenza le sue aspettative sulle autorizzazioni della directory.

Quindi questo crea una classe di problemi che non possono essere facilmente sottoposti a debug strace.

Ma se sei root, c'è una soluzione alternativa! Se il processo di traccia è in esecuzione come root, il processo di traccia può ottenere i privilegi normalmente. Quindi ecco cosa fai:

1. Apri 2 nuovi terminali
2. Nel primo terminale, accedere al computer remoto come root
3. Nel secondo terminale, accedere al computer remoto come utente normale
4. Utilizzare psper ottenere il PID del normale processo di shell dell'utente nel secondo terminale
5. Nel primo terminale, esegui strace -f -p SHELLPID
6. Nel secondo terminale, esegui lo schermo e guardalo fallire
7. Nel primo terminale, ora hai il registro strace che ti serve per scoprire cosa c'è davvero di sbagliato.

L'aggiunta chiave al stracecomando è l' -fopzione, che gli dice di tracciare i processi figlio. È necessario per tracciare lo schermo che sarà figlio del processo shell specificato -p.

Mi piace anche usare -ffe specificare un file di output con -o, come in

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

che creerà un file di output separato per ogni processo figlio. Successivamente li leggi less /tmp/screentrace*e il risultato è di solito più pulito di quello che ottieni usando un singolo -f.

AGGIORNARE

Ora che ho visto l'output di Strace, non so esattamente cosa sia andato storto, ma questa linea è la cosa più sorprendente della traccia:

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

Alcune righe prima, ha creato un pty, che è stato rivelato TIOCGPTNessere il numero 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

Ma non è stato in grado di chown. Non so perché quel chown fallirebbe, ma il fallimento del chown fornisce una ragione plausibile per cui lo schermo ha rinunciato. È possibile ottenere un po 'più di informazioni aggiungendo -valle opzioni di strace e guardando il statdopo il TIOCGPTNper vedere chi possiede la /dev/pts/voce.

Su possibili ragioni di quel bug - politiche selinux errate, ma secondo redhat bugtracker tali errori sono stati corretti in fedora 17/18.

Per ovviare al problema, puoi cambiare la variabile SCREENDIRin te ~/.bashrcin qualcosa del genere $HOME/.screen.

Quando ho riscontrato questo messaggio di errore. Ho dovuto modificare i miei permessi con il seguente:

chmod 2775 /usr/bin/screen

E questo ha risolto il problema per me. Il 2 è molto importante per le autorizzazioni di accesso corrette.

Dovresti leggere di più su SUID, SGID, Sticky Bit, ACL e come influiscono sull'accesso.

Il comando su schermo era già in esecuzione. Quindi l'ho terminato e ho riscritto il comando. Sì, questa non è una risoluzione abbastanza buona come le altre, ma ci vuole meno tempo per farlo.

Basta ps e trovare il pid, uccidere PID e andare di nuovo con il comando di ridigitare lo schermo.

Se si eseguono più comandi su schermo, assicurarsi di terminare il processo corretto associato al proprio terminale.

Ho riscontrato questo problema risolto dopo aver commentato la seguente riga in / etc / fstab e riavviato:

devpts         /dev/pts        devpts  defaults        0       0

Assicurarsi che nessun altro screenstia utilizzando quel dispositivo

Questo può essere ottenuto con /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

E poi uccidi quel processo se è così.

Per qualche motivo, in questa condizione, sudo screenè comunque possibile accedere al dispositivo, ma a quel punto la connessione mancherà i caratteri, che vengono consumati dall'altro screen.

Assicurarsi che l'utente abbia letto e scritto l'autorizzazione per il file

Ad esempio su Ubuntu si desidera aggiungere l'utente al dialoutgruppo: /ubuntu//a/133244/52975

Ho avuto esattamente lo stesso problema e un output di strace abbastanza simile.

Questo risolto:

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

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