“Não é possível definir o grupo de processos do terminal” durante su para outro usuário como shell de login

Nota: Por favor, leia as informações atualizadas começando com "EDITAR" próximo ao meio deste post - o ambiente e o histórico deste problema foram alterados

Eu tenho uma instalação padrão do Debian 6.0 aqui que decidi fazer uma distribuição lateral para os repositórios de teste do Debian. Eu fiz isso trocando as referências aos repositórios Squeeze em meu sources.list para usar os repositórios de testes.

Após a instalação do pacote e a reinicialização, recebo o seguinte erro ao tentar processar - para outro usuário:

root@skaia:~# su joebloggs -
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Se eu omitir o -, isso não ocorre.

Observe que os usuários podem se tornar root corretamente, isso parece acontecer apenas ao mudar de raiz para outra pessoa e usar o - para obter o ambiente desse usuário.

O Google é praticamente inútil aqui. As únicas coisas que consigo encontrar são as referências de 2011 em relação ao suxpacote, que parecem ter sido corrigidas nesse meio tempo.

Isso parece e cheira muito a um erro de atualização, corrigível ajustando o pacote certo da maneira correta. Eu simplesmente não tenho idéia por onde começar - além disso, meu sistema funciona completamente normalmente e conforme o esperado.

EDITAR

Agora isso está acontecendo comigo em uma máquina estável Debian , conforme descrito acima. Desta vez, nenhuma atualização ou nada, apenas estável.

Sim, um ano depois. Ainda não tenho idéia do que diabos é o problema.

Aqui está o que parece agora (pouco mudou):

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
terraria@skaianet:~$ tty
/dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/0
crw--w---- 1 root root 136, 0 Oct 10 19:21 /dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/
crw--w---- 1 root root 136, 0 Oct 10 19:21 0
crw--w---- 1 root root 136, 2 Sep 22 17:47 2
crw--w---- 1 root root 136, 3 Sep 26 19:30 3
c--------- 1 root root   5, 2 Sep  7 10:50 ptmx

Um rastreio gerado assim:

root@skaianet:~$ strace -f -o tracelog su terraria -

..também mostra algum comportamento confuso. Essas mensagens são bastante confusas. Algumas linhas escolhidas:

readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
#Error code 10? 
15503 open("/dev/tty", O_RDWR|O_NONBLOCK) = -1 ENXIO (No such device or address)
#Yes there is, and I can interact with it normally
15503 ioctl(255, TIOCGPGRP, [32561])    = -1 ENOTTY (Inappropriate ioctl for device)

Eu vinculei a saída completa desta sessão de rastreamento - tudo o que fiz foi executar o comando su e, em seguida, imediatamente pressionar Ctrl + d para fora do terminal.

• su - usernameé interpretado por você sucomo "execute o shell do nome de usuário como um shell de logon interativo"
• su username -é interpretado por você sucomo "execute o seguinte comando não interativo ( -) como nome de usuário "
• o último só funcionou porque:
  • seus supasses arrastando argumentos para shpara analisar
  • shleva -para significar "executar como um shell de login (leitura /etc/profile, ...)"

Mas o que você realmente está interessado é: por que não interativo ? Compartilhar o terminal de controle entre o pai privilegiado e o filho sem privilégios deixa você vulnerável à " escalada de privilégios de pushback TTY ", também conhecida como TIOCSTIbug, portanto, a menos que você realmente precise se su desanexar dele . Quando você usou o su username -formulário, su deduziu que não precisava de um terminal de controle .

Somente processos com um terminal de controle podem ter líderes de sessão que manipulam grupos de processos (fazem o controle de tarefas); o rastreamento que você deu é bashdetectar que não pode ser um líder de sessão.

Você menciona:

Onde fica mais estranho é que ambos os formulários funcionam bem no Ubuntu e CentOS 6, no entanto, no baunilha Debian, apenas o primeiro formulário funciona sem erros.

Variantes ignorando gosto suxe sudo, há pelo menos três ^[1] versões suem Linux: coreutils, util-linuxe shadow-utilsa partir do qual Debian de vem. A página de manual deste último aponta:

Esta versão do su tem muitas opções de compilação, das quais apenas algumas podem estar em uso em qualquer site específico.

e o Debian vem com a bandeira old_debian_behavior; outras versões podem ter opções semelhantes em tempo de compilação / tempo de execução. Outra razão para a variabilidade pode ser o fato de haver algum debate ^[2] sobre se sualgum dia deve ser usado para eliminar privilégios dessa maneira e se o TIOCSTIbug é, portanto, um bug (Redhat originalmente o fechou "WONTFIX" ).

[1]: Editar: adicione SimplePAMAppse hardened-shadowa isso.

[2]: O Solar Designer possui algumas opiniões (antigas) que acho que valem a pena ser lidas.

Eu verificaria a propriedade e as permissões em / dev / pts * ou em busca de uma nova configuração para o udev relacionada a dispositivos / dev / pts, que não foi substituída durante o processo de atualização.

Você também pode tentar descobrir qual syscal está gerando o erro executando como root:

strace -f su - username 2>stderr.log