Являются ли мои разрешения для / usr / local / правильными?


88

Я использую HomeBrew для своих портов (кажется, немного «чище», чем MacPorts).

Я могу установить без sudoING (что замечательно), но, похоже, что этап связывания man этого требует ( /usr/local/share/man/man3принадлежит root). Руководство я нашел говорит я рекурсивно , делая
chown /usr/local

sudo chown -R `whoami` /usr/local

Это безопасно ... или это Плохая Идея ™?

Кроме того: мои разрешения правильны?

$ pwd
/usr/local/share/man
$ ls -lah
total 32
drwxrwxr-x    8 root  staff   272B  4 Set 11:02 .
drwxrwxr-x    9 root  staff   306B 10 Set 11:27 ..
drwxr-xr-x    3 root  wheel   102B  4 Ago  2009 de
drwxrwxr-x  163 root  staff   5,4K 10 Set 11:27 man1
drwxr-xr-x   11 root  wheel   374B 10 Set 11:27 man3
drwxr-xr-x    7 ago   staff   238B 10 Set 11:39 man5
drwxr-xr-x   11 ago   staff   374B 10 Set 11:39 man7
-rw-r--r--    1 root  staff    13K  4 Set 11:02 whatis

5
Вот как Homebrew предназначен для использования. Некоторые люди могут не согласиться, но ведущий разработчик говорит, что нужно так поступать.
Майк МакКуэйд

1
Чуть лучшая альтернатива вашему чоуну sudo chown -R :admin /usr/local. Таким образом, он будет работать одинаково для любого администратора системы. Хотя вам также может потребоваться запустить, sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+чтобы убедиться, что у группы такой же доступ на запись, как и у пользователя.
Слипп Д. Томпсон

12
«Я буду использовать homebrew, он кажется чище, чем macports. О, посмотрите на этот плохо определенный беспорядок в разрешениях. Я проверю переполнение стека. О, вот быстрый взлом, который идет вразрез с лучшими практиками Unix и с тем, что пытаются обновить ОС исполнять. Идеально! " Месяц спустя: «Эй, как эта вредоносная программа была установлена?»
hmijail

Проблема, с которой я столкнулся при таком подходе, заключается в том, что он означает, что использовать его может только учетная запись пользователя, которая устанавливает Homebrew. У меня есть Mac с несколькими учетными записями, которые я использую, чтобы отделить рабочие проекты от домашних проектов (например). Если я вошел в неправильную учетную запись, я не могу использовать brew install. Я выбрал этот путь, чтобы избежать опасности использования root, но я не уверен, что это лучший подход.
Прошение

@MikeMcQuaid Мне интересно, что Homebrew наконец-то признал ошибку в этом, и в новой версии, выпущенной неделю или две назад, восстановил разрешения по умолчанию для / usr / local
oemb1905

Ответы:


37

Как правило, лучше придерживаться максимально строгих разрешений. Хранение в /usr/localсобственности rootозначает, что только процессы, которые запускаются как root/ sudo(или запрашивают пользователя с правами администратора через диалоговое окно авторизации Apple), могут писать в эту область. Таким образом, процесс загрузки должен запросить у вас пароль, прежде чем испортить там файлы.

Но, как вы говорите, это затрудняет добавление новых программ.

Я в порядке с запуском sudo, так как вы устанавливаете вещи реже, чем запускаете, но вы должны верить, что процесс сборки ничего не меняет.

Если вы хотите избежать sudo, я бы установил Homebrew ~/usr/localи изменил ваш путь, manpath и т. Д., Чтобы включить в него каталоги.

Лучший способ - создать другого пользователя, скажем, homebrewи создать каталог, принадлежащий этому пользователю. Затем установите там, используя sudo -U homebrew. Другие пользователи будут иметь преимущество в том, что не смогут перезаписывать какие-либо другие файлы, потому что они не работают, а root другие программы не могут повлиять на домашний напиток. (Я отмечаю, что FAQ по Homebrew действительно предлагает этого нового пользователя, если вы находитесь в «многопользовательской среде». Я бы сказал, что любая машина Unix, включая macOS, является многопользовательской средой)

Однако, как говорит вики Homebrew, рецепты не находят все случаи /usr/localи заменяют их выбранным каталогом, я подозреваю, что мы застряли /usr/local.


1
+1 за строгость авторизации, изменение $PATHи $MANPATHвключение пользовательских каталогов. Если установленные программы не требуют общесистемной установки, это гораздо лучшая альтернатива.
2010 г.

3
+1 и принял ответ за «как можно более строгие разрешения». Выполнение brew doctor(предложено ниже) сказало мне, что мне нужно только разделить каталоги общего человека ... достаточно безопасно для меня.
Agos

1
Компромиссное решение, по крайней мере, для людей, заботящихся о безопасности, достаточных для того, чтобы не работать в качестве пользователей-администраторов, заключается в изменении владельца группы и разрешений, чтобы только администраторы могли писать в / usr / local. Смотрите ответ Кенорба.
hmijail

2
@Mark Мне интересно, что Homebrew наконец-то допустил ошибку и в новой версии, выпущенной неделю или две назад, восстановил разрешения по умолчанию для / usr / local
oemb1905

48

Я тоже использую Homebrew и могу подтвердить, что это абсолютно безопасно. Цитирование страницы установки на официальном FAQ по Homebrew :

Сделай себе одолжение и выбери /usr/local

  1. Это проще
    /usr/local/bin уже в твоем PATH.

  2. Проще
    разбить тонны скриптов сборки, если их зависимости отсутствуют в / usr или / usr / local. Мы исправляем это для формул Homebrew (хотя мы не всегда проверяем это), но вы обнаружите, что многие скрипты установки RubyGems и Python ломаются, что находится вне нашего контроля.

  3. Это безопасно
    Apple согласилась с POSIX и оставила этот каталог для нас. Это означает, что /usr/localпо умолчанию каталог отсутствует , поэтому нет необходимости беспокоиться о том, чтобы испортить существующие инструменты.

Если вы планируете устанавливать драгоценные камни, которые зависят от варева, то сэкономьте кучу хлопот и установите на /usr/local!

Нетрудно сказать gem искать в нестандартных каталогах заголовки и dylib. Если вы выбираете /usr/local, все «просто работает!»

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

Ваши разрешения не верны (пока). Просто запустите команду, которую вы перечислили, и все будет в порядке.

Если у вас есть другие проблемы, помните, brew doctorможет помочь вам!


Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
bmike

7
Чат ушел, а жаль. Поэтому, рискуя повторить историю, я оставлю здесь свой комментарий: то, что это сделано, не означает, что это безопасно.
hmijail

4
Суть графика в том, что именно это и предлагает Homebrew, есть причины того, почему это неправильно
user151019

1
brew doctorэто просто потрясающе.
Утку

5
@Carmine Paolino Мне интересно, что Homebrew наконец-то допустил ошибку в этом, и в новой версии, выпущенной неделю или две назад, восстановил разрешения по умолчанию для / usr / local
oemb1905

9

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

Например:

sudo chgrp -R admin /usr/local /Library/Caches/Homebrew
sudo chmod -R g+w /usr/local /Library/Caches/Homebrew

Затем назначьте пользователей, которые должны иметь доступ к brewкоманде для этой группы (проверьте ваши группы через:) id -Gn.

Тогда при работе с brewне запускайте его sudo.

Если проблема не brew doctorустранена , запустите ее для устранения проблемы.


+1 за реальное решение с лучшим поведением, даже если оно еще не закончено. Например: добавить пользователя в группу администраторов на уровне BSD? Разве это не смешивается с концепцией OS X пользователей Admin?
hmijail

Для справки, я следовал этим инструкциям, но просто использовал моего существующего администратора OS X, созданного с помощью графического интерфейса пользователя, вместо добавления кого-либо в какую-либо группу в CLI. Это работает: чтобы иметь возможность запускать команды brew, я должен сначала выполнить su myAdminUser, а затем все работает, как задумано. Но, конечно, это решение не обеспечит никакой безопасности людям, которые все равно уже работают с правами администратора.
hmijail

Наверное, это лучший путь, я согласен с @kenorb
пиксель 67

7

Несмотря на то, что он стоит, /usr/localон не считается "системной" папкой в ​​OS X, а в новой установке Snow Leopard эта папка пуста.

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

Владение /usr/local"работал на меня" на 2 машины более года.

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


5
gcc и другие инструменты разработки автоматически смотрят в / usr / local, так что это влияет на систему
user151019

11
Проблема не в том, что это «системная» папка; дело в том, что это «общесистемная» папка. Даже если там ничего нет, /usr/local/binоно все равно находится в $PATHзначении по умолчанию , и все, что вы там поместите, может быть использовано и другими пользователями, и ему следует доверять . Если весь /usr/local/каталог имеет те же разрешения, которые в /usr/local/share/manнастоящее время имеют настройки OP, любой может пойти и изменить любой двоичный файл с помощью скрипта, который это делает rm -rf ~.
2010 г.

1
слишком рискованно: скорее всего, рано или поздно я установлю MySQL
Agos

2
@Agos: вы всегда можете установить MySQL с HomeBrew, и в этом случае у вас не будет никаких проблем :)
Carmine Paolino

1
@Agos Совсем не рискованно. Предупреждение применяется только в том случае, если вы установили MySQL до Homebrew. Если вы сделаете это впоследствии, разрешения /usr/localдолжны быть в порядке. (Но вы, вероятно, в любом случае используете Postgres. :))
Marnen Laibow-Koser

6

Как и в Homebrew 1.0.0:

Доморощенный больше не должен владеть / usr / local. Если вы хотите, вы можете вернуть / usr / local к владельцу по умолчанию с помощью: sudo chown root: wheel / usr / local


1
В настоящее время я обновляю Brew с использованием brew update, которое все еще требует владения /usr/local. Я постараюсь восстановить разрешения позже.
Джошуа Пинтер

Это действительно отличная информация! Я установил perms, как указано Homebrew (<1.0), и после обновления он дал эти инструкции о том, как их вернуть.
mortona42

0

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


7
Проблема здесь в том, что /usr/local/binдля большинства пользователей вполне может быть начало $ PATH. Создание каталога, доступного для записи, открывает множество пробелов в безопасности.
nohillside

@patrix Так измените пути. :) Если у вас есть скрипты, которые имеют дыры в безопасности из-за неоднозначных путей к командам, я бы обвинял скрипты, а не ваши разрешения - команды, вызываемые в скриптах, обычно должны быть полностью квалифицированы именно по этой причине. В любом случае, нет лучшего решения: либо вы даете своей учетной записи администратора небезопасный umask, либо запускаете все свои сценарии сборки с помощью sudo, либо вы предоставляете некоторым пользователям права на запись /usr/local. Я возьму третий как наименее рискованный ... если вы не знаете лучшего пути.
Марнен Лайбоу-Козер

Хм. Думая об этом еще немного, возможно, лучшим способом было бы сделать так, чтобы Homebrew делал то, что делает RVM по умолчанию: устанавливал все в ~/brewили что-то подобное. Проблема, однако, в том, что в отличие от Ruby, который довольно /usr/local
автономен

3
Я не упомянул, что моя /usr/localне доступна для записи в мире: скорее, у меня есть доверенная группа homebrew(не только администратор), у которой есть права на запись в нее (расширенные права, такие как 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inheritполностью рок). Это лучший компромисс, который мне удалось выяснить: нет sudoсценариев сборки, но есть некоторый контроль над ними /usr/local.
Марнен Лайбоу-Козер

@ MarnenLaibow-Koser Я хотел бы увидеть более подробное объяснение этого подхода (создание доверенной группы пользователей с правами на запись /usr/local). Делая много трала на SO и других сайтах, видя аргументы: перемещать Homebrew в домашнюю папку пользователя или хранить /usr/local, менять владельца и / или группу /usr/localили нет, и так далее ... трудно сказать, есть ли универсально приемлемое решение. У вас есть запись в блоге или статья по этому вопросу, или вы могли бы дать более глубокое объяснение где-нибудь?
Габриэль Л.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.