Por que recebo “screen is terminating” sem raiz?

Question

Eu instalei a tela no Fedora 19. Quando eu testo o comando como root remotamente através do SSH, ele funciona perfeitamente. Por exemplo, se eu inserir screen , um novo emulador de terminal será iniciado e aguardará comandos. Eu posso separá-lo, etc No entanto, quando tento fazer o mesmo, uma vez que eu estou logado remotamente através do SSH como um usuário padrão, o comando termina imediatamente. A única mensagem que vejo é [screen is terminating] .

Alguém já teve esse problema? Está relacionado a permissões ruins?

Atualização:

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

Eu tentei alterar as permissões para 777, mas quando executo screen , obtenho:

Directory '/var/run/screen' must have mode 775.

Portanto, reverti minhas alterações.

    

Answer 1

O flip-flopping entre "must have mode 777" e "must have mode 775" é causado por strace .

screen é geralmente um programa setuid ou setgid. Ele ganha privilégios extras quando é executado, o qual é usado para criar arquivos de socket e / ou modificar o utmp.

Quando um processo está sendo rastreado, setuid e setgid são desativados. O processo de rastreamento, controlado pelo usuário com menos privilégios, pode assumir o processo rastreado, portanto, ele deve ser executado sem seus privilégios extras para evitar que o usuário original tenha muita energia.

screen detecta se está sendo executado com privilégios setuid, privilégios setgid ou nenhum, e ajusta sua expectativa de permissões de diretório de acordo.

Isso cria uma classe de problemas que não podem ser facilmente depurados com strace .

Mas se você for root, há uma solução alternativa! Se o processo de rastreamento estiver sendo executado como root, o processo rastreado poderá obter privilégios normalmente. Então, aqui está o que você faz:

1. Abra 2 novos terminais
2. No primeiro terminal, efetue login na máquina remota como raiz
3. No segundo terminal, efetue login na máquina remota como usuário normal
4. Use ps para obter o PID do processo de shell do usuário normal no segundo terminal
5. No primeiro terminal, execute strace -f -p SHELLPID
6. No segundo terminal, execute a tela e assista a falha
7. No primeiro terminal, você agora tem o log strace que você precisa para descobrir o que está realmente errado.

A adição de chave ao comando strace é a opção -f , que diz para rastrear processos filhos. Você precisa dele para rastrear a tela que será um filho do processo de shell especificado com -p .

Eu também gosto de usar -ff e especificar um arquivo de saída com -o , como em

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

que criará um arquivo de saída separado para cada processo filho. Depois, você os lê com less /tmp/screentrace* e o resultado é geralmente mais limpo do que o obtido com um único -f .

UPDATE

Agora que vi a saída strace, não sei exatamente o que deu errado, mas essa linha é a coisa mais surpreendente no rastreamento:

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

Algumas linhas anteriores, ele criou um pty, que foi revelado por TIOCGPTN como o número 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

Mas não foi possível fazer isso. Eu não sei por que aquele chown iria falhar, mas a falha do chown não dá uma razão plausível para a tela desistir. Você pode obter um pouco mais de informações adicionando -v às opções de strace e observando o stat após o TIOCGPTN para ver quem possui a entrada /dev/pts/ .

    

Answer 2

Em possíveis razões para esse bug - políticas de selinux incorretas, mas de acordo com o redhat bugtracker, tais erros foram corrigidos no fedora 17/18.

Como solução alternativa, você pode alterar a variável SCREENDIR em ~/.bashrc para algo como $HOME/.screen .

    

Answer 3

Eu tenho exatamente o mesmo problema e uma saída de strace bastante semelhante.

Isso corrigiu:

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

créditos: link

    

Answer 4

Quando encontrei esta mensagem de erro. Eu tive que ajustar minhas permissões com o seguinte:

chmod 2775 /usr/bin/screen

E isso resolveu o problema para mim. O 2 é muito importante para as permissões de acesso corretas.

Você deve ler mais sobre SUID, SGID, Sticky Bit, ACL e como eles afetam o acesso.

    

Answer 5

O comando de tela já estava em execução. Então terminei e digitei novamente o comando. Sim, isso não é uma boa resolução como outras, mas leva menos tempo para fazer isso.

Apenas ps e encontre o pid, mate o PID e continue digitando novamente o comando screen.

Se você estiver executando vários comandos de tela, encerre o processo correto associado ao seu terminal.

    

Answer 6

Eu encontrei este problema resolvido depois de comentar a seguinte linha em / etc / fstab e reinicializar:

devpts         /dev/pts        devpts  defaults        0       0

    

Answer 7

Certifique-se de que nenhum outro screen esteja usando esse dispositivo

Isso pode ser obtido com link :

sudo lsof /dev/ttyS0

E, em seguida, mate esse processo se for esse o caso.

Por algum motivo, sob essa condição, sudo screen ainda pode acessar o dispositivo, mas essa conexão perderá caracteres, que são consumidos pelos outros screen .

Certifique-se de que o usuário tenha permissão de leitura e gravação no arquivo

Por exemplo no Ubuntu você quer adicionar o usuário ao grupo dialout : link