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:
- Abra 2 novos terminais
- No primeiro terminal, efetue login na máquina remota como raiz
- No segundo terminal, efetue login na máquina remota como usuário normal
- Use
ps
para obter o PID do processo de shell do usuário normal no segundo terminal - No primeiro terminal, execute
strace -f -p SHELLPID
- No segundo terminal, execute a tela e assista a falha
- 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/
.