È sicuro chown `/ usr / local`?


15

So a cosa /usr/localserve - installare software per la macchina locale. Per impostazione predefinita, rootpossiede la directory. Ciò significa che per installare lì, è necessario utilizzare sudo. Per una macchina per utente singolo o sviluppatore, questo sembra un uso extra non necessario del comando. Quindi, la mia domanda: è sicuro per me possedere /usr/local?

Ad esempio, Homebrew per OS X "Funziona solo" perché possiede /usr/locale installa in modo sicuro il proprio software lì senza l'uso di sudo.

Inoltre, se è installato un software compilato localmente /usr/local, il software attualmente ha bisogno di root per modificarsi o installare plugin. Questo non sembra sicuro - voglio usare solo sudoquando so ESATTAMENTE cosa accadrà.

Opinioni?

Risposte:


5

Non posso raccomandare di diventare il proprietario di /usr/local; per la maggior parte delle situazioni, è probabilmente meno sicuro dell'uso sudo.

La tua domanda suggerisce due motivi che potresti voler fare chown /usr/local.

Il primo è di evitare di dover utilizzare sudoper installare il software. Questo potrebbe leggere ad alcuni (come l'autore di questa risposta ) come dire che vuoi lavorare in modo efficiente o salvare i tasti necessari per digitare sudoe inserire la password. Ma probabilmente quando dici "non necessario", ti riferisci invece al principio del privilegio minimo :

Per impostazione predefinita, rootpossiede la directory. Ciò significa che per installare lì, è necessario utilizzare sudo. Per una macchina per utente singolo o sviluppatore, questo sembra un uso extra non necessario del comando

Spesso ascolto / leggo persone che discutono / lamentano sulla falsariga di "Sono l'unico che usa questo sistema, quindi non dovrei avere bisogno di usare sudoe inserire una password". Per i lettori che sono di quel punto di vista e poiché è rilevante qui, ricordiamo a noi stessi un motivo di sicurezza di base per il root alle proprie cose.

La maggior parte dei file di programma installati su un sistema Ubuntu hanno la modalità file 755, o in notazione simbolica rwxr-xr-x, il che significa che qualsiasi utente o programma può eseguirli , ma solo il proprietario dei file, root, può modificarli. (Tecnicamente questo richiede anche che nessuno tranne root abbia l' wautorizzazione sulla directory che li contiene, quindi altri utenti non possono cancellarli o spostarli.)

Ciò significa che tu, l'umile utente, puoi eseguire qualsiasi programma. Se si tenta di utilizzare un programma per fare qualcosa che non si ha il permesso di fare, come eseguire un'operazione di scrittura su un file di proprietà di root, si verificherà un errore. Questo rende un errore di battitura in un comando, un'applicazione buggy o codice dannoso, meno probabilità di rovinare il sistema - a meno che non sia in esecuzione come root, non avrà l'autorizzazione per farlo. Ciò è particolarmente utile quando si eseguono programmi che interagiscono con Internet.

Se tu chown /usr/local, qualsiasi programma in esecuzione con i tuoi privilegi potresti scrivere file lì, che potrebbero successivamente essere eseguiti come root per qualche motivo, ad esempio sostituendo un altro comando con lo stesso nome. /usr/local/binè nell'impostazione predefinita $PATHe in sudo's secure_path, e precede altre posizioni in entrambi. Quindi, se ho due eseguibili

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

quando eseguo sudo chown ..., l' chownin /usr/local/binverrà eseguito .

Ma probabilmente lo sapevi già, dato che la tua seconda ragione riguarda la sicurezza:

Inoltre, se è installato un software compilato localmente /usr/local, il software attualmente ha bisogno di root per modificarsi o installare plugin. Questo non sembra sicuro - voglio usare solo sudoquando so ESATTAMENTE cosa accadrà.

Nel caso in cui sia necessario menzionarlo qui, è assolutamente corretto (secondo FHS comunque) installare software compilato localmente /usr/local, ma la compilazione stessa dovrebbe essere eseguita da qualche parte nel tuo $HOME, senza sudo, fino all'ultimo passaggio quando si digita sudo make installo equivalente.

Penso che tu stia suggerendo che eseguendo un programma installato /usr/localcome proprietario non privilegiato, potresti utilizzare errori di autorizzazione specifici generati quando tenta di aggiornarsi per vedere che sta cercando di modificare qualche altra posizione del filesystem non di tua proprietà in un modo non voglio, in modo che tu possa impedirgli di farlo.

Questo potrebbe essere utile. L'implicazione è che ti fidi del programma per fare qualsiasi cosa gli piaccia /usr/local, ma non altrove. Se richiede autorizzazioni elevate, è possibile rifiutare di consentire l'aggiornamento o la disinstallazione. Questo ha un senso per me. Ma penso che provare a utilizzare /usr/localcome una sorta di sandbox in questo modo non sia probabilmente una buona idea, o almeno è improbabile che sia la soluzione più sicura. Non è una posizione adeguatamente isolata ( /optè un po 'più isolata, poiché non è quella predefinita $PATH). Il programma potrebbe scrivere o eliminare qualcosa /usr/localper causare danni. Altri programmi (potenzialmente scritti male) che esegui potrebbero scrivere ed eseguire lì codici di cui non sei a conoscenza.

Se sei preoccupato di consentire ad un programma di aggiornarsi in modo sicuro, probabilmente dovresti cercare alternative (forse specifiche del programma, come ad esempio con Python, oppure potresti cercare uno snap o un'implementazione simile adatta alle tue esigenze, o usare container o una VM per testare software potenzialmente non sicuro) prima di esporre un percorso di sistema (anche relativamente utente) da scrivere sui programmi eseguiti da un utente normale. Mi sembra probabile che abbia effetti imprevedibili come consentire ai programmi autorizzazioni temporaneamente elevate con sudo.


6

È insolito che /usr/localnon è di proprietà di root. Ma puoi cambiare il proprietario come desideri.

Ma consiglio di assicurarsi che /usr/local/sbinsia ancora di proprietà rootdi evitare un problema di sicurezza. I comandi qui sono di solito invocati solo da root.


2
Ho fatto un'installazione di Bower in precedenza e il tutorial mi ha suggerito di fare chown -R $ USER / usr / local, quindi ora sto eseguendo chown -R root / usr / local / sbin - ci sono altre cartelle in / usr / local che potrebbero stare meglio con la proprietà di root? Avrei dovuto controllare tutte le autorizzazioni prima di eseguire il comando. "Rimpianto al ritorno" istantaneo.
OnethingSemplice

2
Questa risposta non è soddisfacente e la spiegazione non è davvero corretta. Se, per motivi di sicurezza, è necessario mantenere i comandi basati sulla proprietà di root, che dire dei comandi in /usr/local/binquella radice (e anche di altri utenti) potrebbe essere eseguito? Non dovrebbero essere di proprietà di root? Inoltre, i comandi utilizzati da root, inclusi i comandi in, /usr/local/sbinpossono dipendere dalle librerie condivise in /usr/local/lib. La modifica di tali librerie può apportare modifiche arbitrarie al comportamento dei comandi che le utilizzano. Insistere sul fatto che /usr/local/sbinrestino di proprietà di root sembra del tutto arbitrario.
Eliah Kagan,

5

Per il software solo si ha bisogno, utilizza la home directory, invece di /usr/local.

Invece di modificare la proprietà /usr/localo di eseguire i comandi come root quando non si desidera, è sufficiente configurare le build in modo che vengano installate nella directory home anziché /usr/local. Questo risolve tutti i potenziali problemi con la modifica della proprietà /usr/local, incluso il modo in cui la sua bine le sue sbinsottodirectory sono sul rootpercorso.

Se devi consentire ad altri utenti di eseguire il tuo software, puoi dare loro l'accesso. In effetti, probabilmente lo saranno già, perché per impostazione predefinita la tua directory home ha accesso in lettura ed esecuzione permissivo . (Se non lo vuoi, puoi cambiarlo abbastanza facilmente, semplicemente usando chmodqualsiasi file o directory che vuoi rendere privato e possibilmente anche cambiando il tuo umask.)

Con il software installato nella tua home directory, i binari che sarebbero entrati /usr/local/binandranno invece dentro . Otterrai altre sottodirectory della tua home directory corrispondenti alle sottodirectory di cui necessita il software che installi. Ciò si verifica in genere automaticamente quando si installa il software dal codice sorgente./home/username/bin/usr/local

Configurare le tue build

La maggior parte dei software creati dal codice sorgente prevede un passaggio in cui si esegue:

./configure

Per la stragrande maggioranza del software fornito con uno configurescript che può essere eseguito in questo modo, per impostazione predefinita configura la build per l'installazione all'interno /usr/localquando alla fine si esegue sudo make installper installarlo. Il motivo è che è implicitamente equivalente all'esecuzione:

./configure --prefix=/usr/local

Per configurare una build per l'installazione nella directory home, utilizzare invece questa:

./configure --prefix="$HOME"

In pratica, in Ubuntu, i percorsi della home directory non contengono spazi, altri spazi bianchi o altri caratteri che verranno trattati in modo speciale dalla shell *, quindi a meno che tu non abbia impostato il tuo account utente in modo strano, puoi semplicemente digitare:

./configure --prefix=$HOME

( Tuttavia, non consiglio di prendere l'abitudine per scrivere script . Inoltre, su alcuni altri sistemi operativi - come macOS - è meno raro che i percorsi delle home directory degli utenti contengano spazi.)

Oppure, se preferisci, puoi digitare il percorso completo della tua directory home:

./configure --prefix=/home/username

(Sostituisci usernamecon il tuo vero nome utente, ovviamente. Se per qualche motivo la tua home directory non è in /homeallora dovrai adattarti di conseguenza.)

Installare le tue build

Dopo l'esecuzione make, potresti essere abituato all'esecuzione sudo make install, ma quando si installa nella propria directory home, non è necessario eseguirlo come root, quindi è possibile - e dovrebbe - modificarlo sudo. Corri:

make install

Allo stesso modo, per i software che supportano un uninstalltarget:

make uninstall

Questo è esattamente quello che stavi chiedendo ... proprio nella tua home directory, non /usr/local.

Esecuzione dei programmi

Probabilmente la binsottodirectory della tua home directory è:

  • già nel tuo $PATH, o
  • sarà nel tuo $PATHse ti disconnetti e accedi di nuovo.

Il motivo è che il .profilefile nella tua home directory, che contiene i comandi eseguiti quando accedi, lo contiene per impostazione predefinita per gli account utente creati nella maggior parte delle versioni di Ubuntu (incluso l'account amministratore iniziale creato quando si installa il sistema operativo):

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

Questo codice viene eseguito quando accedi (perché è presente .profile) e inserisce la tua bindirectory personale $PATH solo se esiste in quel momento. Ecco perché potrebbe essere necessario disconnettersi e riconnettersi.

Le versioni precedenti come Ubuntu 14.04, così come le versioni più recenti come Ubuntu 17.10, ne derivano. Tuttavia, Ubuntu 16.04, che è probabilmente la versione più popolare al momento della stesura di questo documento, ha invece questo:

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

Ciò aggiunge semplicemente la binsottodirectory della tua home directory, così come la .local/binsottodirectory, alla tua $PATH, senza controllare se quelle directory effettivamente esistono. Quindi se usi 16.04 o se hai eseguito l'upgrade da un sistema che era 16.04 quando è stato creato il tuo account utente, binprobabilmente la sottodirectory della tua home directory è probabilmente già nella tua $PATH.

Il tuo .profilefile viene copiato dalla /etc/skeldirectory quando viene creato il tuo account utente. Se il tuo account utente è stato creato su una versione precedente di Ubuntu, ha ottenuto quella versione .profilee non è stato modificato, per il tuo account utente, aggiornando a una versione più recente.

Una volta che la binsottodirectory della tua home directory è nella tua $PATH, sarai in grado di eseguire programmi i cui file eseguibili sono installati lì semplicemente digitando i loro nomi, proprio come potresti fare con i programmi installati dal gestore dei pacchetti di Ubuntu o installati all'interno /usr/local.

L' .localopzione

Potresti aver notato che il .profilefile predefinito per gli account utente creati in alcune versioni di Ubuntu, incluso in 16.04 come descritto sopra, aggiunge non solo il $HOME/bintuo percorso, ma anche $HOME/.local/bin. Se .profilenon lo aggiungi, ma lo desideri , puoi semplicemente modificarlo.

Sebbene sia spesso utilizzato per archiviare impostazioni e dati memorizzati nella cache , è anche possibile installare software nella .localsottodirectory della home directory. Dovresti sentirti disinibito nel farlo, poiché dal punto di vista dell'usabilità e della sicurezza --prefix="$HOME/.local"è simile --prefix="$HOME".

Ricorda che i file e le directory che iniziano con .non sono mostrati di default nei browser di file grafici (usa Ctrl+ Hper scoprirli e rivederli) o tramite il lscomando (passa il flag -Ao -aper mostrarli). Questo potrebbe non essere quello che vuoi, o potrebbe essere esattamente quello che vuoi. Questa è una questione di preferenze personali.

Tuttavia, ho osservato che alcuni gestori di pacchetti automatizzati basati su sorgente che compilano e installano software nell'uso della propria directory home $HOME/.local. In realtà non so quanto sia comune - spero di indagare ulteriormente e aggiornare questa risposta - ma potresti preferire utilizzare solo $HOMEper le cose che compili manualmente. In questo modo sarà chiaro da dove provengono le cose. E se c'è una collisione, è probabile che il software coesista in modo accettabile.

È inoltre possibile installare deliberatamente alcuni software $HOME/.locale altri software in $HOME. Tocca a voi. Qualunque bindirectory $PATHvenga visualizzata per prima nella variabile di ambiente è quella da cui verrà eseguito un comando, nel caso in cui esistano comandi con lo stesso nome in entrambi.


Il merito va a Zanna e Videonauth per aver segnalato gli errori in una versione precedente di questa risposta, riguardo a quali versioni di Ubuntu hanno il codice predefinito .profilee aiutandomi a correggerli (vedi anche qui ).


0

Se sudo è un tale inconveniente, basta aggiornare / etc / sudoers in modo da non dover inserire la password quando si esegue sudo. Credo che sia una soluzione migliore rispetto alla modifica del proprietario di / usr / local.


4
Le password non sono il problema: è più l'idea che per installare i moduli in un programma /usr/localsia necessario usare sudo, che è potenzialmente pericoloso.
PR3x,
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.