Le mie autorizzazioni per / usr / local / sono corrette?


85

Sto usando HomeBrew per le mie esigenze di porto (sembra un po '"più pulito" rispetto a MacPorts).

Posso installare senza sudo ing (che è ottimo), ma il passo di collegamento dell'uomo sembra richiederlo ( /usr/local/share/man/man3 è di proprietà di root ).
UN guida L'ho trovato suggerisce in modo ricorsivo chown /usr/local facendo

sudo chown -R `whoami` /usr/local

È sicuro ... o è una cattiva idea ™?

Inoltre: le mie autorizzazioni sono corrette?

$ 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
Ecco come deve essere usato Homebrew. Alcune persone potrebbero non essere d'accordo ma lo sviluppatore principale dice di fare le cose in questo modo.
Mike McQuaid

1
Un'alternativa leggermente migliore al tuo chown: sudo chown -R :admin /usr/local. In questo modo, funzionerà allo stesso modo per qualsiasi utente amministratore della macchina. Anche se potresti aver bisogno di correre sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+ per garantire che il gruppo abbia lo stesso accesso in scrittura dell'utente.
Slipp D. Thompson

12
"Userò homebrew, mi sento più pulito dei macbook.Oh, guarda questo pasticcio dei permessi mal definito. Controllerò Stack Overflow. Oh, ecco un trucco rapido che va contro le migliori pratiche Unix e contro quali aggiornamenti del sistema operativo provare per far rispettare. Perfetto! ". Mese dopo: "Ehi, come è stato installato questo malware?"
hmijail

Il problema che ho con questo approccio è che significa che solo l'account utente che installa Homebrew può usarlo. Ho un Mac con più account che uso per mantenere separati i progetti di lavoro dai progetti di casa (ad esempio). Se sono connesso all'account sbagliato non posso usare brew install. Ho preso questa strada per evitare i pericoli dell'utilizzo di root ma non sono convinto che sia l'approccio migliore.
Auspice

@MikeMcQuaid Trovo interessante il fatto che Homebrew abbia finalmente ammesso l'errore su questo e nella nuova versione rilasciata una o due settimane fa, ha ripristinato i permessi di default su / usr / local
oemb1905

Risposte:


35

Di solito è meglio mantenere le autorizzazioni il più restrittive possibile. conservazione /usr/local posseduto da root significa che solo i processi eseguiti come root / sudo (o chiedere all'utente amministratore tramite la finestra di dialogo di autorizzazione Apple) può scrivere in quest'area. Pertanto, un download di un processo deve chiederti una password prima di corrompere i file lì.

Ma come dici tu, rende più difficile aggiungere nuovi programmi.

Sto bene con la corsa sudo, quando installi le cose meno spesso che eseguirle ma devi credere che il processo di compilazione non cambi nulla che dovrebbe.

Se vuoi evitare sudo, installerei Homebrew in ~/usr/local e modifica il tuo percorso, manpath, ecc. per includere le directory sottostanti.

Un modo migliore è creare un altro utente, ad esempio homebrew e creare una directory di proprietà dell'utente. Quindi, installare lì usando sudo -U homebrew. Gli altri utenti avranno il vantaggio di non essere in grado di sovrascrivere altri file, perché non sono in esecuzione come root e altri programmi non possono influenzare l'homebrew. (Nota che il FAQ Homebrew suggerisce questo nuovo utente se si è in un "ambiente multiutente". Direi che qualsiasi macchina Unix che include macOS è un ambiente multiutente)

Tuttavia, come dice la wiki di Homebrew, le ricette non trovano tutti i casi di /usr/local e sostituirli con la directory scelta. Sospetto che siamo bloccati /usr/local.


1
+1 per mantenere le autorizzazioni rigorose e alterare $PATH e $MANPATH per includere le directory degli utenti. Se i programmi installati non richiedono l'installazione a livello di sistema, è un'alternativa molto migliore.
zneak

3
+1 e risposta accettata per "mantenere le autorizzazioni il più rigorose possibile". fare brew doctor (suggerito sotto) mi ha detto che devo solo chownare le directory degli uomini condivisi ... abbastanza al sicuro per me.
Agos

1
Una soluzione di compromesso, almeno per le persone che si prendono cura della sicurezza abbastanza da non funzionare sempre come amministratori, è modificare la proprietà e le autorizzazioni del gruppo in modo che solo gli amministratori possano scrivere in / usr / local. Vedi la risposta di kenorb.
hmijail

2
@ Mark Io trovo interessante il fatto che Homebrew abbia finalmente ammesso l'errore su questo e nella nuova versione rilasciata una o due settimane fa, ha ripristinato i permessi di default su / usr / local
oemb1905

47

Uso anche Homebrew e posso confermare che è totalmente sicuro. Citando il Installazione pagina sul funzionario FAQ Homebrew :

Fatti un favore e scegli /usr/local

  1. È più facile
    /usr/local/bin è già nel tuo PATH.

  2. È più facile
    Le tonnellate di script di build si interrompono se le loro dipendenze non sono in / usr o / usr / local. Lo sistemiamo per le formule di Homebrew (anche se non lo testiamo sempre), ma scoprirai che molti script di installazione di RubyGems e Python si interrompono e questo è qualcosa fuori dal nostro controllo.

  3. É sicuro
    Apple si è conformata a POSIX e ha lasciato questa directory per noi. Il che significa che non c'è /usr/local directory per impostazione predefinita, quindi non è necessario preoccuparsi di rovinare gli strumenti esistenti.

Se prevedi di installare gemme che dipendono da brews, risparmia un sacco di problemi e installa /usr/local!

Non è banale dire a Gem di cercare in directory non standard per intestazioni e dylibs. Se si sceglie /usr/local, tutto "funziona!"

Lo aggiungerò solo fare le cose come root è una pessima idea , così chown ing /usr/local non solo mi sembra ragionevole (non è una directory di sistema su OSX), ma sano di mente .

Le tue autorizzazioni non sono corrette (ancora). Esegui semplicemente il comando che hai elencato e starai bene.

Se hai altri problemi ricorda, il brew doctor posso aiutarti!


I commenti non sono per discussioni estese; questa conversazione è stata trasferito in chat .
bmike

6
La chat è finita, il che è un peccato. Quindi, a rischio di ripetere la storia, lascerò qui il mio commento: che ciò sia fatto non significa che sia sicuro.
hmijail

3
L'essenza del grafico è anche se questo è ciò che suggerisce Homebrew ci sono motivi per cui questo è sbagliato
Mark

1
brew doctor è semplicemente fantastico
Utku

5
@Carmine Paolino Trovo interessante il fatto che Homebrew abbia finalmente ammesso l'errore su questo e nella nuova versione rilasciata una o due settimane fa, ha ripristinato i permessi di default su / usr / local
oemb1905

8

Se stai usando Homebrew, dovresti dare il permesso di scrittura a un gruppo specifico (entrambi admin o staff ), quindi i file possono essere condivisi tra gli utenti che si trovano in quel gruppo.

Per esempio:

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

Quindi assegnare gli utenti a cui dovrebbe avere accesso brew comando a quel gruppo (controlla i tuoi gruppi tramite: id -Gn ).

Quindi quando si lavora con brew, non eseguirlo con sudo.

Quando si verifica ancora un problema di autorizzazione, esegui brew doctor per risolvere il problema.


+1 per dare una soluzione reale, più ben funzionante, anche se non proprio completata. Ad esempio: aggiungi un utente al gruppo admin a livello BSD? Non si scherza con il concetto di OS X degli utenti Admin?
hmijail

Per la cronaca, ho seguito queste istruzioni, ma ho appena usato il mio utente Admin creato da OS X, invece di aggiungere qualcuno a qualsiasi gruppo nella CLI. Funziona: per poter eseguire i comandi di brew, devo prima farlo su myAdminUsere quindi tutto funziona come previsto. Ma ovviamente questa soluzione non offre alcuna sicurezza per le persone che comunque gestiscono già un utente amministratore.
hmijail

Questo è probabilmente il modo migliore per andare, sono d'accordo con @kenorb
pixel 67

7

Per quello che vale, /usr/local non è considerata una cartella "sistema" da OS X, e su una nuova installazione di Snow Leopard quella cartella è vuota.

Il risultato è qualsiasi roba di proprietà della radice in quella cartella sudo make install su altri software o dare la password dopo aver fatto doppio clic su a .pkg che vuole buttar roba in /usr/local.

possedere /usr/local ha "lavorato per me" su 2 macchine per oltre un anno.

Un trucco è che se hai installato MySQL (non usando Homebrew) e chown i suoi file, allora probabilmente non sarà più in grado di vedere i suoi database (quindi dovresti ridurli a qualunque utente MySQL sia in esecuzione come .)


5
gcc e altri strumenti di sviluppo guardano automaticamente in / usr / local in modo che influenzino il sistema
Mark

11
Il problema non è che si tratta di una cartella "sistema"; è che è una cartella "systemwide". Anche se non c'è niente lì, /usr/local/bin è ancora nell'impostazione predefinita $PATH valore, e qualunque cosa tu abbia messo lì può essere usato anche da altri utenti e dovrebbe esserlo di fiducia . Se il tutto /usr/local/ la directory ha le stesse autorizzazioni /usr/local/share/man attualmente ha la configurazione dell'OP, chiunque può andare a modificare qualsiasi binario con uno script che lo faccia rm -rf ~.
zneak

1
troppo rischioso: è probabile che installerò MySQL prima o poi
Agos

2
@ Agos: puoi sempre installare MySQL con HomeBrew, nel qual caso non avrai problemi :)
Carmine Paolino

1
@Agos Non rischioso affatto. L'avvertenza si applica solo se hai installato MySQL prima di Homebrew. Se lo fai in seguito le autorizzazioni su /usr/local dovrebbe andare bene. (Ma probabilmente usi Postgres comunque. :))
Marnen Laibow-Koser

6

Come in Homebrew 1.0.0:

Homebrew non ha più bisogno di avere la proprietà di / usr / local. Se desideri   è possibile restituire / usr / local alla proprietà predefinita con: sudo chown   root: wheel / usr / local


1
Sto aggiornando attualmente Brew usando brew update, che richiede ancora la proprietà di /usr/local. Proverò a ripristinare le autorizzazioni in seguito.
Joshua Pinter

Questa è davvero una grande notizia! Ho impostato i valori permanenti come specificato da Homebrew (& lt; 1.0) e, dopo l'aggiornamento, ha fornito queste istruzioni su come reimpostarli.
mortona42

0

Penso che sia OK per gli utenti permessi di scrittura a /usr/local - dopo tutto, questo significa che non stai usando sudo su ogni script di costruzione. Non mi piace l'idea di un utente normale possedere /usr/local. Preferirei possedere root (o simili) /usr/local, ma cambia le autorizzazioni in modo che gli utenti (o almeno qualche gruppo privilegiato) possano scrivervi. Sembra l'approccio concettualmente corretto.


7
Il problema qui è questo /usr/local/bin potrebbe essere molto avanti a $ PATH per la maggior parte degli utenti. Rendere la directory scrivibile in tutto il mondo apre molte falle nella sicurezza in questo modo.
nohillside

@patrix Quindi cambia i percorsi. :) Se si dispone di script che presentano lacune di sicurezza dovute a percorsi di comando ambigui, darei la colpa agli script, non alle autorizzazioni: i comandi invocati negli script dovrebbero in genere essere pienamente qualificati esattamente per questo motivo. Ad ogni modo, non c'è soluzione migliore: o dai al tuo account amministratore un umask insicuro, o esegui tutti gli script di build con sudooppure concedi a alcuni utenti i permessi di scrittura /usr/local. Prenderò il terzo come meno rischioso ... a meno che tu non conosca un modo migliore.
Marnen Laibow-Koser

Hmm. Pensandoci ancora un po ', forse un modo migliore sarebbe di fare in modo che Homebrew faccia ciò che RVM fa di default: installa tutto dentro ~/brew o alcuni di questi. Il problema, tuttavia, è che a differenza di Ruby, che è piuttosto autosufficiente, molte utilità * nix si aspettano di trovarsi l'un l'altro /usr/local...
Marnen Laibow-Koser

3
Ho dimenticato di dire che il mio /usr/local non è world-writable: piuttosto, ho un gruppo fidato homebrew (non solo admin) che ha permessi di scrittura (autorizzazioni estese come 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherit totalmente rock). Questo è il miglior compromesso che ho potuto capire: no sudo su script di compilazione, ma alcuni controllo sopra /usr/local.
Marnen Laibow-Koser

@ MarnenLaibow-Koser Mi piacerebbe vedere una spiegazione più approfondita di questo approccio (creando un gruppo fidato di utenti con permessi di scrittura per /usr/local ). Fare un sacco di pesca a strascico su SO e altri siti, vedendo argomenti re: spostare Homebrew nella cartella home dell'utente vs. mantenere in /usr/local, cambiando proprietario e / o gruppo di /usr/local o no, e così via ... è difficile dire se esiste una soluzione universalmente accettabile. Hai un post o un articolo sul blog o potresti fornire una spiegazione più approfondita da qualche parte?
Gabriel L.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.