Sui sistemi simili a UNIX nel corso degli anni (soprattutto per me, Linux), ho notato che .(dir corrente) non è mai in $PATHdefault. Perchè è questo?
Ricordo di aver letto anni fa che si trattava di un problema di sicurezza, ma l'articolo che ho letto non spiegava quale fosse esattamente il problema. È perché qualcuno potrebbe lasciare una versione dannosa di lso cpin una directory, e finirei per eseguirla senza rendermi conto che era lì?
Risposte:
Hai risposto correttamente alla tua domanda, è esattamente per questo che il punto non è sulla strada giusta:
proteggere da virus infantili o errori onesti.
Naturalmente, questa è una misura anti-virus molto scadente e inutile, e nulla ti impedisce di aggiungere punti al percorso tu stesso.
-rfnella directory (rende rm *interessante) ;-)
-rfin primo luogo? ;)
Sì. Se metti il "." nel percorso, si finirebbe per inviare molte chiamate di comando ai file nella directory corrente.
Anche se era l'ultimo, c'è ancora un errore pilota. Ad esempio, in Solaris 10 manca "top". Digito "top" sul mio sistema tutto il giorno, perché penso di essere su un sistema che ha "top".
Mi dispiace, vorrei chiedere questo sotto forma di un commento alla risposta selezionata, ma non ho ancora alcun rappresentante su superutente.
La risposta di sicurezza ha senso, ma se si inserisce "." nel tuo PERCORSO come ultima cosa, la shell non dovrebbe cercare nella directory corrente per ultima mentre cerca i file eseguibili e quindi ridurre il rischio per la sicurezza? Se avesse cercato $ PATH in ordine, avrebbe trovato / bin / ls prima di trovarlo ./ls.
Quindi, quanto è insicuro per me mettere "." alla fine della mia variabile d'ambiente $ PATH?
Funziona come suggerisco. Ecco come ho testato:
Innanzitutto, aggiungi "." alla fine della variabile d'ambiente PATH.
Quindi, inserire il seguente file in alcune directory, come ~ / dir1 / dir2 / test_which.rb:
#!/your/path/to/ruby
puts "this file is from the current directory"
E metti questo file in /usr/bin/test_which.rb
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"
Assicurati di chmod + x i file in modo che siano eseguibili.
Ora, se cambi directory in ~ / dir1 / dir2 ed esegui test_which.rb, otterrai l'output
this file is at /usr/bin/test_which.rbInfatti, se esegui "which test_which.rb" da qualsiasi luogo, dovrebbe riportare
/usr/bin/test_which.rbPuoi comunque eseguire il file nella directory corrente digitando:
./test_which.rbdco slo sduoin una shell, ed è stato salvato da "comando non trovato". Mai.
ls(output a colori e altro) alias a lcui rinuncia completamente ai refusi.
Più che un rischio per la sicurezza, avendo "." nel PERCORSO rendono quasi impossibile assicurarsi che l'esecuzione di qualsiasi comando agisca come previsto. Pensa a eseguire un comando come 'zip' in una grande directory contenente migliaia di file con nomi casuali. La possibilità che uno di questi sia effettivamente chiamato "zip" non è trascurabile e porterebbe a un errore che è molto difficile da capire (in realtà il file dovrebbe essere eseguibile, che, tuttavia, potrebbe accadere).
In particolare, ciò è vero quando si scrivono script che mantengono la variabile PATH dell'utente. Una buona sceneggiatura scritta dovrebbe occuparsi di tutti i casi angolari (come i nomi dei file con spazi o che iniziano con '-'). Ma non è pratico impedire l'esecuzione di un file nella directory corrente anziché un comando di sistema ...
lssarà/usr/bin/lse./lsnon lo sarà. C'è anche l'ostacolo di se sai come aggiungere.alla fine del tuo percorso, probabilmente hai qualche idea su cosa stai facendo. root non dovrebbe mai avere.nel percorso, molti sistemi non consentono nemmeno al root di accedere.