Linux / Comando su: trocar de usuário e usar shells de login

su é uma ferramenta usada para executar um shell ou comandos com identificadores de usuário e de grupo diferentes. Se nenhum usuário for especificado, ele normalmente tem como alvo root, e usar su --login user alterna para um ambiente semelhante ao de fazer login diretamente como aquele usuário.

Um simples su user mantém o diretório de trabalho atual e parte do ambiente, que pode se misturar com as configurações de outro usuário. Para uma troca de conta interativa, geralmente se usa su --login user, e se o objetivo é apenas executar um único comando administrativo, é melhor primeiro considerar se sudo baseado em política é mais apropriado.

O que é o comando su?

su executa comandos com os identificadores (IDs) de outro usuário e de seus grupos. Omitir o nome de usuário tenta iniciar um shell interativo como a conta root.

O su do util-linux realiza autenticação e gerenciamento de contas e sessões através do PAM (Pluggable Authentication Modules, sistema de módulos de autenticação). Qual senha é requerida, se apenas certos grupos podem usar o su, e onde as tentativas são registradas pode variar dependendo do PAM e das configurações de segurança da distribuição.

Este artigo é baseado na implementação do util-linux, que é amplamente utilizada no Linux. O comportamento exato e os arquivos de configuração específicos do sistema podem ser encontrados na página oficial do manual su do util-linux.

Sintaxe básica e troca de contas

A sintaxe básica é a seguinte.

Os exemplos usam contas de demonstração, como deploy e backup. Substitua-as por contas existentes e autorizadas. Os caminhos /usr/local/bin/check-job e /usr/local/bin/backup-job representam programas que precisam existir no sistema; não são instalados pelo comando su.

su [options] [-] [user [arguments...]]

Se nenhum usuário for especificado, ele tenta alternar para a conta root.

su

Quando executado por um usuário comum, normalmente solicita a senha da conta root alvo. Se a conta root estiver bloqueada ou a política PAM não permitir, a troca não pode ser feita mesmo que você conheça a senha da sua conta atual.

Para trocar para um usuário específico, especifique o nome da conta.

su deploy

Para retornar ao shell original, execute exit no shell alternado ou pressione Ctrl+D.

exit

A diferença entre su e su --login

O manual do util-linux recomenda o uso de --login para evitar efeitos colaterais de ambientes mistos. A forma curta - tem o mesmo significado.

su --login deploy
su - deploy

Alterações no ambiente do shell de login

Limpeza das variáveis de ambiente existentes

O su --login do util-linux limpa o ambiente existente, exceto por TERM, COLORTERM, NO_COLOR, e variáveis explicitamente permitidas. Em seguida, inicializa HOME, SHELL, USER, LOGNAME e PATH com base no usuário de destino.

O ambiente final também pode refletir valores adicionados ou modificados por módulos PAM, portanto, não se deve presumir que seja exatamente o mesmo entre distribuições.

Mover para o diretório pessoal do usuário de destino

--login inicia o shell de login após mover-se para o diretório pessoal do usuário de destino. Após a troca, você pode verificar o usuário, diretório pessoal e diretório de trabalho com os seguintes comandos.

id
printf '%s\n' "$HOME"
pwd

Arquivos de inicialização lidos pelo shell

O shell de login lê arquivos de inicialização para login de acordo com as regras do shell utilizado. Para o Bash, ele pode ser influenciado pelas configurações do sistema e do usuário, como /etc/profile e ~/.bash_profile. Verifique o manual do shell alvo e as configurações da conta para a ordem real.

Opções de su frequentemente usadas

Execute um único comando como outro usuário

Execute um comando com -c

Se você não precisar permanecer em um shell interativo, pode passar comandos para o shell do usuário de destino com -c.

su -c 'id' deploy

Quando o comando terminar, su também termina e retorna ao shell original. Como a string do comando é reinterpretada pelo shell de destino, tenha cuidado com aspas, expansão de variáveis e o momento da redirecionamento.

Executando comandos em um ambiente de login

Para executar comandos no ambiente de login e no diretório pessoal do usuário de destino, use --login juntamente.

su --login -c 'pwd; id' deploy

Ambos os comandos conectados por um ponto e vírgula são executados dentro do shell do usuário de destino. Não passe strings criadas dinamicamente com privilégios elevados diretamente se elas incluírem entrada externa, pois isso apresenta risco de injeção de comandos.

Verificando o código de saída dos comandos

su geralmente retorna o código de saída do comando executado. Na implementação do util-linux, ele retorna 126 se o comando não puder ser executado, 127 se o comando não for encontrado, e 1 para erros gerais antes da execução do comando.

su -c '/usr/local/bin/check-job' deploy
status=$?
printf 'exit=%s\n' "$status"

Em automação, você deve verificar não apenas a string de saída, mas também o código de saída.

Shells e contas com restrições

Shell padrão do usuário de destino

A menos que especificado de outra forma, o shell definido na entrada passwd da conta de destino geralmente é usado; na ausência dessa informação, usa-se /bin/sh. Ao verificar informações da conta, não modifique arbitrariamente todo o /etc/passwd; em vez disso, consulte-o da seguinte forma.

getent passwd deploy

Especifique o shell com -s

Você pode especificar um shell diferente com -s.

su -s /bin/sh -c 'id' deploy

Se o shell da conta de destino for um shell restrito não listada em /etc/shells, o shell especificado por um usuário comum pode ser ignorada. Só porque root pode contornar a restrição não significa que é seguro abrir um shell interativo para uma conta de serviço.

Respeite a finalidade das contas de serviço

Contas com nologin ou false definidas como seu shell provavelmente não são destinadas a logins interativos. Se você precisar trabalhar com tal conta, execute apenas o comando necessário e primeiro verifique se há comandos de gerenciamento fornecidos pelo serviço ou se há recursos do systemd disponíveis.

Use a preservação de variáveis de ambiente com cuidado

Significado de --preserve-environment

A opção --preserve-environment preserva o ambiente atual sem redefinir HOME, SHELL, USER ou LOGNAME. Ela é ignorada se especificada com --login.

su --preserve-environment deploy

A menos que seja um caso especial em que as configurações do usuário que está chamando devem ser passadas como estão, misturar o diretório pessoal e o ambiente de execução de usuários diferentes pode levar a alterações inesperadas na propriedade ou configuração de arquivos.

Permita apenas variáveis necessárias

No util-linux, você pode preservar apenas as variáveis necessárias combinando --login e --whitelist-environment.

su --login --whitelist-environment=LANG,LC_ALL deploy

HOME, SHELL, USER, LOGNAME e PATH estão excluídos da lista de permissões. Variáveis de locale (configuração regional) também podem afetar o comportamento do programa, então passe apenas valores que sejam absolutamente necessários.

Diferença entre su e sudo

O método de autenticação e a gravação de logs podem variar de acordo com o PAM e a política, portanto, a tabela acima é uma comparação geral. Se apenas um comando root for necessário, sudo, que pode limitar privilégios por comando, pode evitar a necessidade de compartilhar a senha da conta de destino. Para uso detalhado, consulte comando sudo e configuração do sudoers.

Por que a troca para a conta root pode falhar

A conta root pode estar bloqueada

Algumas distribuições desativam o login por senha para a conta root por padrão e usam administração através do sudo. Neste caso, inserir a senha do usuário atual em su - não terá sucesso.

Se o usuário tiver privilégios de sudo e a política permitir, um shell root estilo login pode ser aberto da seguinte forma, mas se apenas comandos individuais forem necessários, é mais seguro usar sudo command em vez de um shell de administrador.

sudo -i

O PAM ou políticas de grupo podem impor restrições

A política em /etc/pam.d/su pode restringir o uso de su a grupos específicos ou impor requisitos adicionais de autenticação. Não enfraqueça arbitrariamente as configurações do PAM para obter privilégios; em vez disso, forneça ao administrador do sistema as tarefas necessárias e as contas-alvo.

Pode haver problemas com o status da conta-alvo

A troca pode falhar devido à expiração da conta, bloqueio, diretório inicial incorreto, shell restrito ou permissões de arquivo. Se você for um administrador, verifique a causa com getent passwd user, ferramentas de gerenciamento de contas e logs de autenticação.

Quando root executa como outro usuário

runuser pode ser mais adequado para automação

O manual do util-linux já recomenda runuser ao executar como outro usuário a partir de um processo com privilégios elevados ou scripts do root. runuser não é set-user-ID, não requer autenticação por senha e utiliza uma configuração PAM separada.

O manual de runuser do util-linux detalha a exigência de execução por root e o uso de uma configuração PAM separada.

runuser -u backup -- /usr/local/bin/backup-job

runuser é uma ferramenta administrativa usada pelo root, portanto, não é um comando para um usuário comum obter privilégios em vez do sudo.

Se uma sessão PAM não for necessária, reconsidere o propósito

Se você simplesmente precisa alterar IDs de usuário/grupo e atributos de permissão para executar um programa e uma sessão PAM não é necessária, o util-linux também sugere setpriv como uma alternativa. Esta ferramenta gerencia diretamente privilégios e atributos de segurança, então deve ser usada apenas por administradores que entendam exatamente as configurações de usuário, grupo, grupo suplementar e capacidades.

Separe a sessão com um pseudoterminal

Separação fornecida por --pty

--pty cria um pseudoterminal independente entre a sessão original e a sessão alvo, e o su retransmite a entrada e saída. Isso pode melhorar a segurança ao impedir que as duas sessões compartilhem diretamente o mesmo terminal em uma sessão interativa.

su --pty --login deploy

Não é uma sessão completa de login do systemd

Mesmo ao usar su --login, isso não cria uma sessão de login completamente nova do ponto de vista do systemd-logind. Se você precisar de tarefas que exijam serviços de usuário, seats (conjuntos de dispositivos locais) ou limites de sessão reais, deve considerar ferramentas adequadas para esse propósito, como systemd-run ou machinectl.

Precauções de segurança

• Não compartilhe a senha root ou as senhas de outros usuários com várias pessoas.
• Não coloque senhas na linha de comando, no histórico do shell, em scripts ou pipes.
• Não mantenha um shell root aberto por mais tempo do que o necessário; exit imediatamente após concluir o trabalho.
• Imediatamente após a troca, verifique id, pwd e HOME para evitar confusão entre usuários e caminhos.
• Para comandos a serem executados com privilégios elevados, primeiro revise as opções, caminhos de destino e resultados das expansões de curinga.
• Não presuma que os logs sejam retidos; em vez disso, verifique as configurações reais e políticas de retenção do PAM, journal e logs de autenticação.

Comandos executados após abrir um shell root com su são separados dos registros de autenticação do próprio su. Se auditoria de comandos individuais for necessária, você deve projetá-la juntamente com auditoria de shell, registro centralizado ou métodos como sudo que fornecem políticas por comando.

Problemas comuns e soluções

Perguntas frequentes

A senha de quem você deve digitar para o su?

Geralmente, você digita a senha do usuário de destino para o qual deseja alternar. No entanto, se o root executá-lo ou as políticas PAM usarem métodos de autenticação diferentes, o comportamento pode variar. É normal que os caracteres não sejam exibidos na tela ao digitar a senha.

Qual é a diferença entre su e su -?

su executa um shell de root mantendo o diretório atual e parte do ambiente. su - muda para o diretório pessoal do root e configura o ambiente de login. No util-linux, a forma de login é recomendada para reduzir a mistura de ambientes.

Como verificar o usuário atual após trocar com su?

id é útil para verificar juntos tanto o usuário e grupo real quanto o efetivo. Se você só precisa do nome de usuário simples, pode usar whoami, mas para verificar grupos suplementares, id fornece mais informações.

É aceitável colocar a senha do su no script?

Não. A senha pode ser exposta em arquivos, informações de processos ou logs. Se estiver automatizando como root, use runuser com a conta e o comando necessários para a tarefa. Se for para elevação de privilégios como usuário comum, crie uma forma que não insira a senha, como usar regras de sudoers com privilégios mínimos ou um serviço dedicado para a tarefa.

Resumo

Para alternância de conta interativa geral, você pode usar su --login user, e para um único comando, su -c 'command' user. Um simples su user pode misturar ambientes, então é bom verificar id, HOME e pwd após a troca.

Se o objetivo é executar apenas um comando root, sudo, que fornece controle de permissão por comando e auditoria, pode ser mais apropriado. Ao executar como outro usuário em automação root, considere runuser. Você também pode verificar ferramentas básicas relacionadas juntas na lista de comandos comumente usados no Linux (em inglês).