Qual é a diferença entre o login como usuário e a mudança de usuários usando o su através do root?

Question

Quando você tiver um servidor de algum tipo, poderá acessá-lo por meio de, por exemplo, ssh user1@ip e também ssh root@ip para ir ao seu usuário root com su priveleges e ir para su user1 . Em meu pensamento, ambas as maneiras devem me levar ao mesmo ambiente de usuário (neste caso, "user1"), mas na minha experiência real não, porque em ssh user1@ip há coisas instaladas que em su user1 não há .

Por que isso?

    

Answer 1

O SSH inicia um shell de login. su , por padrão, não.

Em particular, isso significa que ~/.profile (ou arquivo semelhante) para esse usuário não é originado. Portanto, as alterações feitas em ~/.profile não serão efetivadas. Também pode ser o caso que:

• mesmo se você iniciar um shell de login, foram feitas alterações diferentes no ~/.profile do root, o que pode poluir o ambiente do usuário.
  • /etc/profile e /etc/profile.d/* podem aplicar configurações de maneira diferente para usuários diferentes (não por padrão, no entanto)
• pode haver configurações diferentes para diferentes usuários na configuração do SSH.

• A configuração do PAM é diferente. Por exemplo, /etc/pam.d/ssh tem:

  session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
  

  considerando que /etc/pam.d/su tem:

  session       required   pam_env.so readenv=1 envfile=/etc/default/locale
  

  Isso significa que o SSH carrega ~/.pam_environment , mas su não. Este é um grande problema, pois ~/.pam_environment é o local independente de shell para variáveis de ambiente, e é aplicado se você efetuar login a partir da GUI, do TTY ou do SSH.

Para iniciar um shell de login, execute um dos seguintes:

su - <username>
sudo -iu <username>

Exemplo:

# su muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
# su - muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /home/muru/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
# sudo -iu muru sh -c 'echo $HOME $PATH'
/home/muru /home/muru/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# sudo -u muru sh -c 'echo $HOME $PATH'
/root /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# ssh muru@localhost 'echo $HOME $PATH'
/home/muru /home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Mesmo com o SSH, se você executar um comando em vez de iniciar um shell, um shell de login não será executado (observe a ausência de ~/bin no teste SSH, que está presente em su - e sudo -i ). Para obter o resultado verdadeiro, executarei meu shell como um shell de login:

# ssh muru@localhost '$SHELL -ilc "echo $HOME $PATH"'
/home/muru /home/muru/bin:/home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

É também por isso que sudo su e sudo -s são formas ruins de obter um shell de root. Ambas as formas são poluídas pelo meio ambiente.

Relacionados:

• Unix & amp; Linux: su vs sudo vs sudo -i vs sudo bash

Answer 2

Em geral, é principalmente uma diferença estratégica.

Se você estiver logado como um superusuário, você pode alterar qualquer coisa o tempo todo ... ou seja, não há proteção contra erros catastróficos, você teria que mudar temporariamente para outro usuário por segurança.

Considerando que: se você está logado com privilégios limitados, você evita algum risco de erros catastróficos, porque você tem que mudar intencionalmente para su root para acesso temporário àquele poder, mas agora você tem a posição de retorno padrão para um usuário seguro.

A diferença é, portanto, realmente estratégica, não técnica.