В чем разница между именем пользователя и пользователем, использующим su через root?

Когда у вас есть какой-либо сервер, вы можете получить к нему доступ, например, ssh user1@ip и вы также можете сделать ssh root@ip чтобы перейти к вашему пользователю root с помощью su priveleges, а затем перейти к su user1 . По моему мнению, оба эти способа должны привести меня к одной и той же пользовательской среде (в данном случае «user1»), но в моем фактическом опыте это не так, потому что в ssh user1@ip есть вещи, установленные в su user1 нет ,

Почему это?

SSH запускает оболочку входа. su , по умолчанию нет.

В частности, это означает, что файл ~/.profile (или аналогичный файл) для этого пользователя не используется. Таким образом, изменения, сделанные в ~/.profile , не вступят в силу. Возможно также, что:

  • даже если вы запустите оболочку входа в систему, в корневой файл ~/.profile были внесены изменения, которые могут загрязнять среду пользователя.
    • /etc/profile и /etc/profile.d/* могут применяться по-разному для разных пользователей (но не по умолчанию)
  • в настройках SSH могут быть разные настройки для разных пользователей.
  • Конфигурация PAM отличается. Например, /etc/pam.d/ssh имеет:

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

    в то время как /etc/pam.d/su имеет:

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

    Это означает, что SSH загружает ~/.pam_environment , но su нет. Это большой, так как ~/.pam_environment – это не ~/.pam_environment от оболочки место для переменных среды, и оно применяется, если вы входите в GUI, TTY или SSH.

Чтобы запустить оболочку входа, запустите либо:

 su - <username> sudo -iu <username> 

Пример:

 # 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 

Даже с SSH, если вы запустите команду вместо запуска оболочки, оболочка входа не будет запущена (обратите внимание на отсутствие ~/bin в тесте SSH, который присутствует в su - и sudo -i ). Чтобы получить истинный результат, я запустил свою оболочку в качестве оболочки входа:

 # 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 

Вот почему sudo su и sudo -s – это дрянные способы получить корневую оболочку. Оба эти пути загрязнены окружающей средой.


Связанный:

  • Unix & Linux: su vs sudo -s vs sudo -i vs sudo bash

По большому счету это в основном стратегическое различие.

Если вы вошли в систему как суперпользователь, вы можете что-то менять все время … т.е. – нет защиты от катастрофических ошибок, вам придется временно переключиться на другого пользователя для обеспечения безопасности.

Принимая во внимание, что если вы вошли в систему с ограниченными привилегиями, вы избегаете риска катастрофических ошибок, потому что вы должны намеренно переключиться на su root для временного доступа к этой мощности, но теперь у вас есть позиция падения по умолчанию для безопасного пользователя ,

Следовательно, разница действительно стратегическая, а не техническая.