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


17

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

Это почему?

Ответы:


15

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являются дрянными способами получить корневую оболочку. Оба эти способа загрязнены окружающей средой.


Связанный:


2
Кажется, я должен бодрствовать, прежде чем браться за вопросы :). Ваш ответ замечательный, а мой пропущен, чтобы найти правильный ответ. Молодцы +1
Видеонавт

-1

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

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

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

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


Вопрос не был точно в том, насколько пользователь root отличается от других пользователей. Это была разница между доступом к серверу пользователя напрямую через ssh и доступом к нему через su уже внутри пользователя root. Во всяком случае, я согласен с тем, что вы сказали тоже, ха-ха, спасибо
Мигель Корти

Ах, хорошо, извините ... Мне действительно было интересно, почему все вдавались в технические детали, наверное, я неправильно понял ваше намерение.
господин президент
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.