Когда у вас есть какой-либо сервер, вы можете получить к нему доступ, например, ssh user1@ipи также ssh root@ipможете перейти к своему корневому пользователю с su привилегиями и затем перейти к su user1. По моему мнению, оба эти способа должны привести меня к одной и той же пользовательской среде (в данном случае, «user1»), но, по моему опыту, это не так, потому что в ssh user1@ipнем установлены вещи, su user1которых нет.
Это почему?
SSH запускает оболочку входа. suпо умолчанию нет.
В частности, это означает, что ~/.profile(или аналогичный файл) для этого пользователя не получен. Поэтому внесенные изменения ~/.profileне вступят в силу. Возможно также, что:
~/.profileвносятся различные изменения , которые могут загрязнять среду пользователя.
/etc/profileи /etc/profile.d/*может по-разному применять настройки для разных пользователей (но не по умолчанию)Конфигурация 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как это независимое от оболочки место для переменных среды, и оно применяется, если вы входите из 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являются дрянными способами получить корневую оболочку. Оба эти способа загрязнены окружающей средой.
Связанный:
По большому счету это в основном стратегическая разница.
Если вы вошли в систему как суперпользователь, вы можете все время что-то менять ... то есть - нет защиты от катастрофических ошибок, вам придется временно перейти на другого пользователя для безопасности.
Принимая во внимание, что: если вы вошли в систему с ограниченными правами, вы избежите некоторого риска катастрофических ошибок, потому что вам нужно намеренно перейти на su root для временного доступа к этой возможности, но теперь у вас есть запасная позиция по умолчанию для безопасного пользователя. ,
Поэтому разница действительно стратегическая, а не техническая.
источник