Окружающая среда, аналогичная ожидаемой пользователем, если пользователь зарегистрировался непосредственно [dубликат]

Question 1

Другой подход:

declare -A foo    # associative array

foo["directory"]="d"
foo["file"]="f"
foo["link"]="l"

find /etc -type ${foo["$1"]}

Question 2

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

Связано:

, даже если вы запустили оболочку входа, в корневом каталоге ~/.profile были внесены различные изменения, которые могут загрязнять среду пользователя , /etc/profile и /etc/profile.d/* могут применять настройки по-разному для разных пользователей (но не по умолчанию)

Question 3

Question 4

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

Связано:

, даже если вы запустили оболочку входа, в корневом каталоге ~/.profile были внесены различные изменения, которые могут загрязнять среду пользователя , /etc/profile и /etc/profile.d/* могут применять настройки по-разному для разных пользователей (но не по умолчанию)

Question 5

В основном это стратегическая разница.

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

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

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

Question 6

В основном это стратегическая разница.

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

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

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

Community · Accepted Answer · 18 July 2018 в 09:09

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

Связано:

, даже если вы запустили оболочку входа, в корневом каталоге ~/.profile были внесены различные изменения, которые могут загрязнять среду пользователя , /etc/profile и /etc/profile.d/* могут применять настройки по-разному для разных пользователей (но не по умолчанию)

Community · Accepted Answer · 24 July 2018 в 19:16

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

Связано:

, даже если вы запустили оболочку входа, в корневом каталоге ~/.profile были внесены различные изменения, которые могут загрязнять среду пользователя , /etc/profile и /etc/profile.d/* могут применять настройки по-разному для разных пользователей (но не по умолчанию)

Mr.President · Answer 3 · 18 July 2018 в 09:09

В основном это стратегическая разница.

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

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

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

Mr.President · Answer 4 · 24 July 2018 в 19:16

В основном это стратегическая разница.

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

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

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

Вопрос заключался не в разнице между пользователем root от других пользователей. Это была разница между доступом пользователя к серверу напрямую через ssh и доступом к нему через su уже внутри пользователя root. В любом случае, я согласен с тем, что вы сказали слишком ха-ха, спасибо — Miguel Corti, 15 June 2016 в 02:03
Ах, извините, извините ... Я действительно задавался вопросом, почему все вникают в технические подробности, я думаю, я неправильно понял ваше намерение. — Mr.President, 16 June 2016 в 02:32

Окружающая среда, аналогичная ожидаемой пользователем, если пользователь зарегистрировался непосредственно [dубликат]

4 ответа

Другие вопросы по тегам:

Похожие вопросы: