Яка різниця між логіном як користувачем та зміною користувачів, які використовують su через root?

Якщо у вас є якийсь сервер, ви можете отримати доступ до нього через, наприклад, ssh user1@ipі ви також ssh root@ipможете перейти до свого кореневого користувача з 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це місце, незалежне від оболонки, для змінних оточуючих середовищ, і застосовується, якщо ви увійдете з 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 для тимчасового доступу до цієї влади, але тепер у вас є безпечне положення за замовчуванням для безпечного користувача .

Тому різниця дійсно стратегічна, а не технічна.