`Sudo pip install` è ancora una pratica fallita?


38

Sono nuovo di Ubuntu, quindi per favore abbi pazienza. Ho installato pipcon questo comando: sudo apt-get -y install python-pip. Poi ho installato NLTK utilizzando il comando sul loro sito web, che è stato: sudo pip install -U nltk. Ma poi mi sono imbattuto in questa domanda che dice che tutto ciò che ho fatto è stata una "pratica interrotta". La linea che mi ha colpito di più era che l'uso sudo pipè intrinsecamente sbagliato e che dare piptroppa forza potrebbe danneggiare i file del sistema operativo. Qualcuno può convalidare questo reclamo?

Nota: l'ho usato solo sudoperché quando ho provato il comando apt-get -y install python-pipmi ha dato 2 errori:

E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

3
Le istruzioni fornite sudo pip installsono intrinsecamente sbagliate. - da stackoverflow.com/a/33004920/95735
Piotr Dobrogost

"... intrinsecamente ...." pshaw
michael

Siamo spiacenti, sudo pip installva male come le curl "some-url" | sudo bashinstallazioni. Allo stesso modo, abbiamo avuto alcune volte in cui alcuni sviluppatori erano soliti sudo pip installinstallare una dipendenza sulla propria stazione di lavoro, quindi hanno archiviato il codice non funzionante nel repository perché il file requirements.txto setup.pymancava qualsiasi cosa fosse installata e tutti gli altri dovevano capire quale dipendenza fosse necessaria mentre il ragazzo era in vacanza.
Mike DeSimone il

Risposte:


52

Entrambe sudo pip installe l'altra variante comune nonsudo -H pip install dovrebbero essere incoraggiate perché è un rischio per la sicurezza usare i privilegi di root da usare per installare i pacchetti Python da PyPI (Python Package Index).pip

Da https://stackoverflow.com/a/21056000/486919 (sottolineatura mia):

Quando corri pipcon sudo, corri setup.pycon sudo. In altre parole, esegui codice Python arbitrario da Internet come root. Se qualcuno inserisce un progetto dannoso su PyPI e lo installi, dai a un utente malintenzionato l'accesso alla tua macchina come root. Prima di alcune recenti correzioni su pipe PyPI, un utente malintenzionato poteva anche eseguire un uomo nel mezzo dell'attacco per iniettare il proprio codice quando si scarica un progetto affidabile.

Come menzionato in https://security.stackexchange.com/a/79327/8761 , è importante notare che chiunque può caricare pacchetti Python, compresi quelli dannosi, su PyPI.

In breve, in conformità con il principio del privilegio minimo , non utilizzare sudocon pipper installare i pacchetti Python da PyPI a meno che non sia assolutamente necessario. Invece, considera l'utilizzo di pip install --user(nota che pip installal momento sudonon ci sono opzioni / flag aggiuntive predefinite pip install --usersu Ubuntu) o ambienti virtuali (come virtualenv). Se vedi persone che raccomandano sudo pipo sudo -H pip, per favore, digli di non farlo.


2
Se l'ho usato in passato, come posso ripulire quello che ha fatto?
endolito

1
Quindi queste istruzioni sono sbagliate? tensorflow.org/install/install_linux
endolith

5
@endolith puoi annullare la disinstallazione di pip per annullare. Inoltre, se il pacchetto proviene da un manutentore fidato, come tensorflow, numpy, ecc., "Aye! Security!" l'argomento non ha davvero senso. (Anche se installi un pacchetto dannoso, anche come "--user", in pratica sei comunque fregato. La vera regola dovrebbe essere: non installare codice da persone sconosciute / non fidate ... tranne che in un contenitore - ma anche allora, non raccomandato.)
michael

2
@endolith Quelle istruzioni non dicono di usare sudo. Forse lo erano e hanno visto l'errore dei loro modi? :)
David Gardner,

1
sudo pip installpuò disinstallare "vecchi" pacchetti Python installati dal sistema, il che può rendere difficile l'aggiornamento o la disinstallazione di tali pacchetti del sistema operativo. sudo pip uninstallnon aiuta qui, perché rimuove il nuovo pacchetto ma non ripristina i file da quello vecchio. (Il mio collega R. Zagar approfondisce i dettagli in un'altra risposta.)
Mike DeSimone il

19

Devi usare sudoper installare pip con apt ( sudo apt install python-pip), ma come indicato nella risposta di edwinksl non dovresti usare sudoper installare pacchetti con pip , dovresti usarepip install --user <package> per installare solo per il tuo utente, o usare un virtualenv per limitare ulteriormente l'ambito del pacchetto .

Apt installa pacchetti dai repository di Ubuntu, mentre pip installa pacchetti caricati dall'utente da PyPi che potrebbero essere dannosi.


7

E per una risposta più moderata:

  1. Davvero devi sempre sudo apt-get install ... , è così che lo strumento è stato progettato per funzionare.
  2. L'uso sudo [-H]con pip installè sia possibile sia facoltativo, a seconda di cosa esattamente si vuole fare (e quindi "polemica").

Uno dei motti di Python è "Dovrebbe esserci uno - e preferibilmente solo un - modo evidente di farlo." E come la maggior parte dei motti, è rotto con allegria sardonica apparentemente in ogni occasione possibile. (Ecco perché i motti esistono, immagino.) Sfortunatamente, secondo la mia più umile opinione, l'ecosistema Python è costituito da molte regole "hard & fast" contrastanti , da non infrangere mai ... tranne quando "yada yada yada" (diavolo, dettagli, ecc.). In quasi tutti i casi, ciò è dovuto all'evoluzione storica della lingua e degli strumenti (e chi vuole / ha bisogno di una lezione di storia quando vuole solo andare avanti con il proprio lavoro) - ma può anche essere dovuto alle differenze in Mac / Win / * Piattaforme Nix (ad es. Unix / Linux ha una mentalità simile,prendi tutte queste "pratiche rotte" e " cultisti del male intrinsecamente sbagliati" con un enorme pizzico di sale. Alcuni in realtà significano bene. (Altri sono solo, beh, cattivi.)

Prima di tutto, piuttosto che "installazioni per utente" di base, preferirai quasi sempre un virtualenv, perché in realtà è probabilmente quello di cui avrai bisogno. Quindi potresti anche iniziare con questo ora. Come ciò avvenga esattamente "dipende" (vedi il motto di Python, sopra). Se stai usando Conda (principalmente per Mac e Windows), verrà impostato usando Conda . Se usi "puro" Python [sic] , dipende da quale versione e quali programmi di utilità python hai, ma virtualenvwrapper è piuttosto utile.

In secondo luogo, proprio come contro-esempio della regola "mai sudo", potresti preferire sudo -H pip install -U numpy, il che è perfettamente bene, anche vantaggioso, in quanto può consentire di evitare di scaricare / reinstallare / mantenere grandi librerie, dove vuoi solo / serve una versione, in ogni virtualenv separatamente. Grandi framework popolari come scikit-learn, NumPy, matplotlib, SciPy, panda, ecc., Possono essere installati una volta e fatti e riutilizzati in tutti gli ambienti . Inoltre, l'amministratore di sistema locale potrebbe essere in grado di installarli per ogni utente su un sistema - e ovviamente lo farebbero anche tramite sudo, ad esempio, per installazioni più complicate, come TensorFlow.

E, infine, se stai installando una libreria di terze parti casuale che fa cose del genere (API di Twitter, munging del testo, formattazione del codice, ecc.), Sono pienamente d'accordo: non installarlo come root tramite sudo. Certo, installalo come utente corrente. Ma ricorda, il tuo account utente ha tutte le tue cose davvero importanti .


2
Dove "temperato" = "controproducente strizzare la mano affievolendo confusione per il gusto di cercare di non ferire i sentimenti di nessuno". Sii chiaro ed esplicito per evitare confusione: non è mai necessario farlo come base, inclusi i tuoi esempi. Unix è davvero "tira su la tua configurazione e rischi", è letteralmente una mentalità C, ma come lì, non usare mallocdove non è necessario. La --userbandiera fa ciò che l'OP stava chiedendo e non richiede autorizzazioni speciali. Stai minando i tuoi punti positivi su virtualenv nel processo ... niente di "cultista del carico" in tutto ciò.
Benjamin R,

Ho già incluso questa prospettiva nel mio sondaggio di risposte e opinioni comuni (se si legge da vicino).
michael

1

L'uso di "sudo pip install" può e sovrascriverà il contenuto di Python fornito dal tuo fornitore di SO. Quando ciò accade, tutti i pacchetti fornitore interessati da questo non passeranno un "rpm --verify" e i tuoi pacchetti sembreranno corrotti.

Desideri utilizzare gli strumenti di amministrazione del sistema che il tuo fornitore di sistema operativo ha testato o utilizzare componenti non testati scaricati da Internet?

Quando, non se, un pacchetto dannoso viene caricato su PyPI ... le persone che usano "sudo pip install" finiranno per eseguire quel payload dannoso con i privilegi di sistema completi. Lo vuoi? (#Principleofleastprivilege)

Se è solo il tuo laptop e stai solo rischiando alcune foto di gatti, allora il rischio è probabilmente basso ... ma se si tratta di un sistema multiutente, il rischio è ora moltiplicato per N. Se hai dati sul il sistema che ha valore o la disponibilità o l'affidabilità del sistema hanno valore, quindi anche i rischi aumentano.

Sentiti libero di scegliere la tua avventura, ma ottieni il consenso informato degli altri utenti che potrebbero essere interessati dalla tua scelta. Potrebbero non sentirti a tuo agio con il tuo stesso livello di rischio.


0

Per aggiungere a queste risposte: non conosco Ubuntu, ma su Fedora sono in grado di utilizzare il sudo dnf install python3-numpyformato per installare MOLTI pacchetti utili per me. Ciò non ha lo svantaggio di essere insicuro (il manutentore del repo distro ha pacchetti convalidati), ma consente anche di installare a livello di sistema. L'unico inconveniente è che le versioni del repository distro potrebbero essere leggermente in ritardo rispetto ai pacchetti in PyPI.


-1

No, questo è corretto. Non posso convalidare questa affermazione. Uso sempre sudo -Hcon pip. pippuò danneggiare solo i file del sistema operativo apt. Non utilizzare solo sudocon pipquando si desidera installare solo per quell'utente.


1
Sul personal computer, quando è necessario installare a livello di pipsistema? Se sei un amministratore di sistema, forse questa è una storia diversa.
Benjamin R,
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.