Безопасно ли использовать chown `/ usr / local`?

Я знаю для чего /usr/local- установка программного обеспечения для локальной машины. По умолчанию rootвладеет каталогом. Это значит, что для установки там нужно пользоваться sudo. Для компьютера с одним пользователем или разработчика это кажется ненужным дополнительным использованием команды. Отсюда мой вопрос - безопасно ли мне владеть /usr/local?

Например, Homebrew для OS X «Просто работает», потому что они владеют /usr/localи безопасно устанавливают там свое программное обеспечение без использования sudo.

Кроме того, если у вас установлено локально скомпилированное программное обеспечение /usr/local, ему в настоящее время необходим root для изменения себя или установки плагинов. Это кажется небезопасным - я хочу использовать только sudoтогда, когда я точно знаю, что произойдет.

Мнения?

Я не могу рекомендовать стать владельцем /usr/local; для большинства ситуаций это, вероятно, менее безопасно, чем использование sudo.

Ваш вопрос предлагает две причины, по которым вы можете захотеть chown /usr/local.

Во-первых, чтобы избежать необходимости использовать sudoдля установки программного обеспечения. Для некоторых (например, автора этого ответа ) это может означать, что вы хотите работать эффективно или сохранить нажатия клавиш, необходимые для ввода sudoи ввода пароля. Но, вероятно, когда вы говорите «ненужный», вы вместо этого ссылаетесь на принцип наименьших привилегий :

По умолчанию rootвладеет каталогом. Это значит, что для установки там нужно пользоваться sudo. Для компьютера с одним пользователем или разработчика это кажется ненужным дополнительным использованием команды

Я довольно часто слышу / читаю людей, высказывающих мнение / жалующихся по типу «Я единственный, кто использует эту систему, поэтому мне не нужно использовать sudoи вводить пароль». Для читателей, которые придерживаются этого мнения, и поскольку это актуально здесь, давайте напомним себе об основной причине безопасности для корня к собственным вещам.

Большинство программных файлов, установленных в системе Ubuntu, имеют файловый режим 755 или в символической записи rwxr-xr-x, что означает, что их может выполнить любой пользователь или программа , но изменять их может только владелец файлов root. (Технически это также требует, чтобы никто, кроме root, не имел wразрешения на каталог, который их содержит, поэтому другие пользователи не могут удалять или перемещать их.)

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

Если вы chown /usr/local, любая программа, работающая с вашими привилегиями, может записывать туда файлы, которые впоследствии могут быть выполнены от имени пользователя root по какой-либо причине, например, путем замены другой команды с тем же именем. /usr/local/binнаходится в по умолчанию $PATH, и в sudo«с secure_path, и речь идет , прежде чем в других местах в обоих. Так что, если у меня есть два исполняемых файла

/usr/local/bin/chown
/bin/chown

когда я исполняю sudo chown ..., в будет выполняться .chown/usr/local/bin

Но вы, наверное, уже все это знали, поскольку ваша вторая причина связана с безопасностью:

Кроме того, если у вас установлено локально скомпилированное программное обеспечение /usr/local, ему в настоящее время необходим root для изменения себя или установки плагинов. Это кажется небезопасным - я хочу использовать только sudoтогда, когда я точно знаю, что произойдет.

_{На тот случай, если здесь необходимо упомянуть об этом, абсолютно правильно (в любом случае, в соответствии с FHS) устанавливать локально скомпилированное программное обеспечение /usr/local, но сама компиляция должна выполняться где-то в вашем $HOME, без sudo, до последнего шага, когда вы печатаете sudo make installили эквивалентны.}

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

Это может быть полезно. Подразумевается, что вы доверяете программе делать все, что ей нравится /usr/local, но не где-то еще. Если он запрашивает повышенные разрешения, вы можете отказать ему в обновлении или удалить его. Это имеет некоторый смысл для меня. Но я думаю, что пытаться использовать /usr/localв качестве своего рода песочницу таким способом, вероятно, не очень хорошая идея, или, по крайней мере, вряд ли это будет самое безопасное решение. Это не должным образом изолированное место ( /optнемного более изолированно, так как не по умолчанию $PATH). Программа может написать или удалить что-то, что /usr/localможет причинить вред. Другие (потенциально плохо написанные) программы, которые вы запускаете, могут писать и выполнять код там, о котором вы не знаете.

Если вы беспокоитесь о том, чтобы позволить программе безопасно обновлять себя, вам, вероятно, следует поискать альтернативы (возможно, специфичные для программы, как, например, с python), или вы могли бы искать оснастку или аналогичную реализацию, которая соответствует вашим потребностям, или использовать контейнеры или виртуальная машина для тестирования потенциально небезопасного программного обеспечения), прежде чем открывать системное местоположение (даже относительно пользовательское) для записи программами, запускаемыми обычным пользователем. Мне кажется, что это может привести к непредсказуемым последствиям, так как разрешение программам временно повысить разрешения sudo.

Это необычно, что /usr/localне принадлежит root. Но вы можете изменить владельца, как вы хотите.

Но я советую убедиться, что /usr/local/sbinэто все еще принадлежит, rootчтобы избежать проблемы безопасности. Команды здесь обычно вызываются только пользователем root.

Для программного обеспечения только вам нужно использовать свой домашний каталог вместо /usr/local.

Вместо того, чтобы менять владельца /usr/localили запускать команды от имени пользователя root, когда вы этого не хотите, вам следует просто настроить свои сборки так, чтобы они устанавливались в вашем домашнем каталоге вместо /usr/local. Это решает все потенциальные проблемы с изменением владельца /usr/local, включая то, как его binи sbinподкаталоги находятся на rootпути России.

Если вам нужно разрешить другим пользователям запускать ваше программное обеспечение, вы можете предоставить им доступ. На самом деле, они, вероятно, уже смогут, потому что по умолчанию ваш домашний каталог имеет разрешающий доступ для чтения и выполнения . (Если вы не хотите этого, вы можете изменить его довольно легко, просто используя chmodлюбые файлы или каталоги, которые вы хотите сделать приватными, и, возможно, также изменив свой umask.)

С установленным программным обеспечением в вашей домашней директории, исполняемые файлы , которые пошли бы в /usr/local/binвместо этого идти . Вы получите другие подкаталоги вашего домашнего каталога, соответствующие подкаталогам того программного обеспечения, которое вам нужно установить. Обычно это происходит автоматически при установке программного обеспечения из исходного кода./home/username/bin/usr/local

Конфигурирование ваших сборок

Большая часть программного обеспечения, которое вы создаете из исходного кода, имеет этап, на котором вы запускаете

./configure

Для подавляющего большинства программного обеспечения, поставляемого со configureскриптом, который может быть запущен таким образом, по умолчанию конфигурируется сборка для установки внутри, /usr/localкогда вы в конечном итоге запускаете sudo make installее установку. Причина в том, что это неявно эквивалентно выполнению:

./configure --prefix=/usr/local

Чтобы настроить сборку для установки в домашний каталог, используйте вместо этого:

./configure --prefix="$HOME"

На практике в Ubuntu пути к домашним каталогам не содержат пробелов, других пробелов или других символов, которые будут обрабатываться подобной оболочкой, например *, если вы не настроили свою учетную запись довольно странно, вы можете просто набрать:

./configure --prefix=$HOME

(Однако я не рекомендую использовать это для написания сценариев . Кроме того, в некоторых других ОС, таких как macOS, пути к домашним каталогам пользователей нередко содержат пробелы.)

Или, если вы предпочитаете, вы можете ввести полный путь к домашней директории:

./configure --prefix=/home/username

( usernameКонечно, замените ваше фактическое имя пользователя. Если по какой-то причине вашего домашнего каталога нет, /homeвам придется соответствующим образом изменить его.)

Установка ваших сборок

После запуска makeвы можете привыкнуть к запуску sudo make install, но когда вы устанавливаете в свой домашний каталог, вам не нужно запускать его как root, так что вы можете - и должны --omit sudo. Просто беги:

make install

Точно так же для программного обеспечения, которое поддерживает uninstallцель:

make uninstall

Это именно то, что вы просили ... просто в вашем домашнем каталоге, а не /usr/local.

Запуск ваших программ

Возможноbin подкаталог вашего домашнего каталога является:

• уже в вашем $PATH, или
• будет в вашем, $PATHесли вы просто выйдите и вернетесь.

Причина в том, что .profileфайл в вашем домашнем каталоге, который содержит команды, которые запускаются при входе в систему, содержит это по умолчанию для учетных записей пользователей, созданных в большинстве версий Ubuntu (включая первоначальную учетную запись администратора, созданную при установке ОС):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Этот код запускается, когда вы входите в систему (потому что он есть .profile) и размещает ваш личный binкаталог $PATH только в том случае, если он существует в то время. Вот почему вам может потребоваться выйти из системы и вернуться обратно.

Старые версии, такие как Ubuntu 14.04, а также новые версии, такие как Ubuntu 17.10, поставляются с этим. Тем не менее, Ubuntu 16.04, который, вероятно, является самым популярным релизом на момент написания этой статьи, имеет следующее:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

Это просто добавляет binподкаталог вашего домашнего каталога - а также .local/binподкаталог - в ваш $PATH, не проверяя, существуют ли эти каталоги на самом деле. Так что если вы используете 16.04, или при обновлении от системы , которая была 16,04 , когда была создана ваша учетная запись пользователя, то binподкаталог вашего домашнего каталога, скорее всего , уже в вашем $PATH.

Ваш .profileфайл копируется из /etc/skelкаталога при создании учетной записи пользователя. Если ваша учетная запись пользователя была создана в более старом выпуске Ubuntu, она получила эту версию .profileи не была изменена - для вашей учетной записи пользователя - путем обновления до более позднего выпуска.

Как только binподкаталог вашего домашнего каталога окажется в вашем $PATH, вы сможете запускать программы, исполняемые файлы которых установлены там, просто вводя их имена, так же, как вы могли бы делать это с программами, установленными менеджером пакетов Ubuntu или установленными внутри /usr/local.

.localВариант

Возможно, вы заметили, что .profileфайл по умолчанию для учетных записей пользователей, созданный в некоторых выпусках Ubuntu, в том числе в 16.04, как описано выше, добавляет не только $HOME/binваш путь, но и $HOME/.local/bin. Если ваш .profileне добавляет это, но вы хотите, чтобы, то вы можете просто отредактировать его в.

Хотя это часто используется для хранения настроек и кэшированных данных , вы также можете установить программное обеспечение внутри .localподкаталога вашего домашнего каталога. Вы должны чувствовать себя свободными в этом, так как с точки зрения юзабилити и безопасности --prefix="$HOME/.local"это похоже на --prefix="$HOME".

Помните, что файлы и каталоги, которые начинаются с ., не отображаются по умолчанию в графических браузерах файлов (используйте Ctrl+, Hчтобы их отобразить или скрыть) или lsкомандой (передайте флаг -Aили, -aчтобы показать их). Это может быть не то, что вы хотите, или это может быть именно то, что вы хотите. Это вопрос личных предпочтений.

Однако я заметил, что некоторые автоматизированные менеджеры пакетов на основе исходного кода, которые создают и устанавливают программное обеспечение в своем домашнем каталоге, используют $HOME/.local. На самом деле я не знаю, насколько это распространено - я надеюсь продолжить исследование и обновить этот ответ - но вы можете предпочесть просто использовать $HOMEвещи, которые вы компилируете вручную. Таким образом, будет ясно, откуда все пошло. И если есть столкновение, программное обеспечение все еще может сосуществовать приемлемо.

Вы также можете намеренно установить некоторое программное обеспечение в $HOME/.localи другое программное обеспечение в $HOME. Тебе решать. Какая бы binдиректория ни была первой в вашей $PATHпеременной среды, это та, из которой будет выполняться команда, в случае, если команды с одинаковыми именами существуют в обеих.

Заслуга Zanna и Videonauth для указывая на ошибки в предыдущей версии этого ответа, о том, каких релизах Ubuntu есть какой код по умолчанию в .profile, и помогают мне исправить их (смотрите также здесь ).

Если sudo вызывает такие неудобства, просто обновите / etc / sudoers, чтобы вам не приходилось вводить пароль при запуске sudo. Я считаю, что это лучшее решение, чем смена владельца / usr / local.