Чи правильні мої дозволи на / usr / local / правильні?

88

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

Я можу встановити без sudoing (що чудово), але, схоже, потрібен крок, який пов'язує людину ( /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
terminal  macports  permission  homebrew 
— Агос
джерело
5
Ось як мається на увазі використання Homebrew. Деякі люди можуть не погодитися, але головний розробник каже робити так.
— Майк МакКвайд
1
Трохи краще альтернатива вашому Чаун: sudo chown -R :admin /usr/local. Таким чином, він буде працювати однаково для будь-якого користувача адміністратора машини. Хоча вам також може знадобитися запустити, sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+щоб група мала такий самий доступ для запису, як і користувач.
— Сліп Д. Томпсон
12
"Я використовую домашню мову, вона виглядає більш чистою, ніж макпорти. О, подивіться на цей невдалий дозвіл на дозвіл. Я перевірю в" Переповнення стека ". О, ось швидкий злом, який суперечить кращим практикам Unix та тим, що намагаються оновити ОС. виконувати. Ідеально! ". Місяць пізніше: "Гей, як це встановлено це зловмисне програмне забезпечення?"
— hmijail
Проблема, яку я маю з таким підходом, полягає в тому, що він означає, що користуватися ним може лише обліковий запис користувача, який встановлює Homebrew. У мене є Mac з кількома обліковими записами, які я використовую, щоб робочі проекти були окремими від домашніх проектів (наприклад). Якщо я ввійшов у неправильний обліковий запис, я не можу використовувати встановлення пива. Я пройшов цей маршрут, щоб уникнути небезпеки використання root, але не переконаний, що це найкращий підхід.
— Auspice
@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.

— користувач151019
джерело
1
+1 для суворого дотримання авторизацій, зміни $PATHта $MANPATHвключення каталогів користувачів. Якщо встановлені програми не потребують загальнодоступної установки, це набагато краща альтернатива.
— zneak
3
+1 та прийнята відповідь за "зберігати дозволи максимально суворо". Здійснення brew doctor(запропоноване нижче) сказало мені, що я повинен лише заглушити довідники спільної людини ... досить безпечні для мене.
— Agos
1
Компромісне рішення, принаймні для людей, які доглядають за безпекою, щоб не працювати як користувачі адміністратора весь час, - це змінити власність і дозволи групи, щоб лише адміністратори могли писати в / usr / local. Дивіться відповідь kenorb.
— hmijail
2
@Mark Мені здається цікавим, що Homebrew нарешті визнав провину в цьому, і в новій версії, випущеній тиждень-два тому, відновив дозволи за замовчуванням до / usr / local
— oemb1905
48

Я також використовую Homebrew і можу підтвердити, що це абсолютно безпечно. Цитуючи сторінку встановлення на офіційному поширеному запиті про домашню мову :

Зробіть собі прихильність і виберіть /usr/local

  1. Легше
    /usr/local/bin вже у вашому PATH.

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

  3. Це безпечно, що
    Apple відповіла POSIX і залишила цей каталог нам. Це означає, що /usr/localза замовчуванням немає каталогу, тому не потрібно турбуватися про те, щоб зіпсувати існуючі інструменти.

Якщо ви плануєте встановити дорогоцінні камені, які залежать від варіння, тоді заощадите собі клопоту і встановіть /usr/local!

Не банально сказати, що дорогоцінний камінь шукає нестандартні каталоги для заголовків і дилібів. Якщо ви виберете /usr/local, все "просто працює!"

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

Ваші дозволи не є правильними (поки що). Просто запустіть команду, яку ви перерахували, і у вас все буде добре.

Якщо у вас є інші проблеми, пам’ятайте, що brew doctorдопоможе вам!

— Кармін Паоліно
джерело
Коментарі не для розширеного обговорення; ця розмова переміщена до чату .
— bmike
7
Чат пропав, що шкода. Тож, ризикуючи повторити історію, я залишу тут свій коментар: те, що це зроблено, не означає, що це безпечно.
— hmijail
4
Суть діаграми полягає в тому, що саме це говорить те, що Homebrew припускає, що є причини, чому це не так
— користувач151019
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щоб усунути проблему.

— kenorb
джерело
+1 за надання фактичного, більш сприятливого рішення, навіть якщо воно не справді закінчено. Наприклад: додати користувача до групи адміністратора на рівні BSD? Хіба це не заплутається з концепцією OS X користувачів адміністраторів?
— hmijail
Для запису я дотримувався цих інструкцій, але просто використовував свого існуючого користувача адміністратора OS X GUI, а не додав кого-небудь до будь-якої групи в CLI. Це працює: щоб мати змогу запускати команди варити, я спочатку повинен робити su myAdminUser, а потім все працює за призначенням. Але, звичайно, це рішення не надасть жодної безпеки людям, які все одно вже користуються користувачем адміністратора.
— hmijail
Це, мабуть, найкращий шлях, я згоден з @kenorb
— піксель 67,
7

Що це варто, /usr/localце не вважається "системною" папкою OS X, і на абсолютно новій Snow Leopard встановити цю папку порожньо.

Будь-які кореневі речі у цій папці є результатом sudo make installіншого програмного забезпечення або наданням вашого пароля після подвійного клацання клавіші a, .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наразі є у налаштуваннях ОП, будь-хто може перейти та змінити будь-який двійковий файл із сценарієм rm -rf ~.
— zneak
1
занадто ризиковано: ймовірно, я рано чи пізно встановлю MySQL
— Agos,
2
@Agos: ви завжди можете встановити MySQL з HomeBrew, і в цьому випадку у вас не виникне жодних проблем :)
— Carmine Paolino
1
@Agos Зовсім не ризиковано. Застереження застосовується лише в тому випадку, якщо ви встановили MySQL перед Homebrew. Якщо ви це зробите після цього, дозволи на отримання /usr/localповинні бути нормальними. (Але ви, мабуть, все-таки використовуєте Postgres. :))
— Marnen Laibow-Koser
6

Як і в Homebrew 1.0.0:

Homebrew більше не повинен мати право власності на / 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. Я вважаю за краще мати власний root (або подібний) /usr/local, але змінити дозволи, щоб користувачі (або хоча б якась привілейована група) могли писати на нього. Це здається концептуально правильним підходом.

— Марнен Лайбоу-Козер
джерело
7
Проблема тут полягає в тому, що /usr/local/binдля більшості користувачів цілком може опинитися на передній частині $ PATH. Створення каталогів у світовому режимі відкриває безліч отворів у безпеці.
— nohillside
@patrix Отже, змінюйте шляхи. :) Якщо у вас є сценарії, у яких є отвори в захисті через неоднозначні командні шляхи, я б звинувачував скрипти, а не ваші дозволи - команди, викликані в сценаріях, зазвичай повинні бути повністю кваліфіковані саме з цієї причини. У будь-якому разі, немає кращого рішення: або ви даєте обліковому запису адміністратора незахищений умаск, або запускаєте всі свої сценарії побудови sudo, або даєте деяким користувачам права на запис /usr/local. Я візьму третю як найменш ризиковану ... якщо ви не знаєте кращого способу.
— Marnen Laibow-Koser
Хм. Якщо подумати над цим ще трохи, можливо, кращим способом було б дозволити Homebrew робити те, що робить RVM за замовчуванням: встановити все в ~/brewщось подібне. Проблема, однак, полягає в тому, що на відміну від Рубі, яка є досить самодостатньою, багато * nix утиліти розраховують знайти один одного в /usr/local...
— Marnen Laibow-Koser
3
Я нехтував зазначенням того, що мій список /usr/localне піддається світовому запису: швидше, у мене є довірена група homebrew(не лише адміністратор), яка має дозволу на запис на нього (розширені дозволи, такі як 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inheritповністю рок). Це найкращий компроміс, який я зміг зрозуміти: не sudoна сценарії побудови, а на деякий контроль над /usr/local.
— Marnen Laibow-Koser
@ MarnenLaibow-Koser Я хотів би побачити більш поглиблене пояснення цього підходу (створення довіреної групи користувачів з дозволом на запис /usr/local). Виконуючи багато тралів на SO та інших сайтах, бачачи аргументи щодо: переміщення Homebrew у домашню папку користувача порівняно з тим, як зберігати /usr/local, змінювати власника та / або групу /usr/localчи ні тощо., Важко сказати, чи є загальноприйнятне рішення. Чи є у вас блог чи стаття з цього приводу чи ви могли десь дати більш глибоке пояснення?
— Габріель Л.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.