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

Это необычно, что /usr/local не принадлежит root. Но вы можете менять владельца по своему усмотрению.

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

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

Я не могу рекомендовать стать владельцем /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, но сама компиляция должна выполняться где-то в вашем [ 1124], без sudo, до последнего шага при вводе sudo make install или эквивалентного.}

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

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

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

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

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

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

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

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

Программное обеспечение Most, которое Вы создаете из исходного кода, имеет шаг, куда Вы работаете:

./configure

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

./configure --prefix=/usr/local

Для конфигурирования сборки для установки в корневом каталоге используйте это вместо этого:

./configure --prefix="$HOME"

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

./configure --prefix=$HOME

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

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

./configure --prefix=/home/username

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

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

После выполнения make, Вы можете быть приучены к выполнению sudo make install, но когда Вы устанавливаете в своем собственном корневом каталоге, Вы не должны выполнять его как корень, таким образом, Вы можете - и если - опускают 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, и помощь мне исправить их (см. также здесь).