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

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

Это почему?

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

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

• даже если вы запускаете оболочку входа в систему, в root ~/.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как это независимое от оболочки место для переменных среды, и оно применяется, если вы входите из 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 против sudo -s против sudo -i против sudo bash

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

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

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

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