Gli script che richiedono sudo falliscono se non ce l'hanno o usano sudo e prompt?

26

Ho una sceneggiatura che mi dà un controllo approfondito sulla luminosità della retroilluminazione e richiede sudol'esecuzione. È essenzialmente questo:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | tee $backlight

e vive a ~/bin/backlight-adjust. Lo script ha bisogno di sudoprivilegi, perché tee $backlightsta scrivendo in una posizione privilegiata. Quindi fallirà se non viene eseguito con sudo.

Questo approccio ha un problema, perché non posso solo correre sudo backlight-adjust, perché ~/binnon è in $PATHin sudoambiente, solo nel mio ambiente. Quindi dovrei correre sudo env "PATH=$PATH" backlight-adjusto qualcosa di simile.

In alternativa, avrei potuto scriverlo in questo modo:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | sudo tee $backlight

e chiedimi la password.

Il secondo approccio funziona meglio per me perché non devo ricordare di digitare sudo; mi spingerà. E posso mantenere $PATHintatto il mio . Tutto ciò sembra più conveniente, ma ci sono dei motivi per cui non dovrei farlo nel secondo modo?

(Sto usando Xubuntu 14.04 e la mia shell è GNU bash 4.2.45, se questo fa la differenza.)

bash shell-script sudo

— John Feminella
fonte

Grazie per la correzione. Sto eseguendo un Debian (LMDE) modificato e il mio sudoeffettivamente mantiene il mio $PATHdi default, quindi non ho questo problema.

— terdon

27

Personalmente, userei un approccio diverso. Crea un alias per la tua sceneggiatura. Aggiungi questa linea al tuo ~/.bashrc(o equivalente in altre shell)

alias backlight-adjust='sudo ~/bin/backlight-adjust'

In questo modo, non devi preoccuparti di ricordarti di eseguirlo sudoe non devi aggiungere sudolo script. Sarà completamente trasparente per te e chiederai semplicemente la tua password quando proverai ad eseguire backlight-adjust.

— terdon
fonte

Questo sembra un approccio molto sensato e quello con un impatto minimo sul resto del sistema. +1.

— John Feminella,

@JohnFeminella D'altra parte, se mai vuoi condividere questo script con qualcun altro, anche loro avranno bisogno dell'alias. Personalmente, non vedo alcun motivo per non inserire sudolo script reale, soprattutto perché ciò consente di vedere facilmente quali elementi dello script richiedono effettivamente i permessi di root.

— Kyle Strand

@KyleStrand no, non lo faranno. Il comando chiamato dallo script si lamenterà semplicemente di non avere accesso.

— terdon

@terdon Riconosco che avrei potuto essere leggermente più chiaro, ma presumibilmente sai cosa intendevo dire: il destinatario della sceneggiatura dovrà affrontare lo stesso problema originariamente affrontato dall'autore della sceneggiatura, e come coscienzioso sceneggiatore, l'autore dovrebbe anche condividere la loro soluzione personale a questo particolare dilemma di utilizzo.

— Kyle Strand

@KyleStrand sì, ma non c'erano problemi, l'unico problema che l'OP aveva era che non voleva "ricordarsi di digitare sudo" a parte questo, lo script sarà perfettamente portatile. Il mio punto è che l'alias è completamente opzionale e non risolve nulla, ne semplifica l'utilizzo.

— terdon

7

Non riesco a capire perché potrebbe essere errato --- anche se normalmente preferisco che i comandi non mi chiedano cose, in modo che siano programmabili. Puoi modificare /etc/sudoersper farlo sudofunzionare senza una password.

Ma ... perché non aggiungere

chgrp  one-of-your-groups-here /sys/class/backlight/acpi_video0/brightness     
chmod g+w /sys/class/backlight/acpi_video0/brightness

nel tuo /etc/rc.locale ti dimentichi di sudo?

(In Ubuntu, se sei in grado di usarlo, sudosei nel gruppo sudo , quindi puoi usarlo chgrp sudo /sys...ed essere felice con esso.)

— Rmano
fonte

3

In alternativa, è possibile aggiungere

Defaults        env_keep +="PATH"

al tuo /etc/sudoersfile.

— Mog
fonte

2

Si afferma sudo backlight-Adjust, perché ~ / bin non si trova in $ PATH nell'ambiente sudo

Quindi perché dipendere da quello? Penso che dovresti semplicemente cambiare quella linea /home/user/bin/backlight-adjuste funzionerà.

Ma mi piacerebbe molto anche la soluzione di Terdon di usare un alias. Oppure puoi inserire il tuo script /usr/bin/e sarà disponibile per ogni utente (incl. Root)

— ExploWare
fonte

Sì, ma è fastidioso farlo. Altrimenti, a che serve metterlo nel mio $ PATH in primo luogo? Inoltre, mi piace averlo ~/binperché allora è sotto il repository dotfile di casa mia, quindi rimane sotto controllo della versione.

— John Feminella,

@JohnFeminella a proposito, non c'è motivo di cambiare percorso, basta usare la -Ebandiera per preservare l'ambiente:sudo -E command

— terdon

@terdon Che non funziona in Debian; è ignorato per motivi di sicurezza. Dovresti passare esplicitamente le variabili d'ambiente, come ho detto nella mia domanda ( sudo env "PATH=$PATH" ...).

— John Feminella,

1

Non è possibile dare una regola generale ... se lo script / programma è progettato per eseguire alcune riconfigurazioni (ad es. Una stampante) ed essere chiamato da utenti regolari, è necessario. Altrimenti, lascerei abbastanza bene da solo: se un utente normale lo esegue, fallisco (o a seguito di un controllo esplicito o solo perché non è permesso fare qualcosa).

Privilegi elevati dovrebbero essere distribuiti con parsimonia, se non del tutto. Passare a un privilegio superiore è difficile, meglio lasciarlo agli esperti (ad es sudo(1).).

— vonbrand
fonte

0

Personalmente uso qualcosa come ${SUDO}nei miei script, in modo che il chiamante possa impostarlo, se necessario, o ${SUDO:-sudo}usarlo per impostazione predefinita.

Nel tuo caso specifico, sono con la risposta accettata, però.

— mirabilos
fonte

-1

Metti lo script (senza il sudo) in una posizione appropriata per l'utente, come /bin, quindi fai questo:

sudo chown root /bin/backlight-adjust
sudo chmod 4755 /bin/backlight-adjust

Funziona impostando il flag setuid, il che significa che verrà sempre eseguito come proprietario del file. Per i dettagli, leggere http://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/ . Non so davvero molto di come funzioni, l'ho appena trovato su Google basandomi su qualcosa che pensavo di aver letto qualche anno fa.

— AJMansfield
fonte

1

Gli script di Shell non possono più essere impostati, grazie al cielo ... Questa è una risposta assolutamente malvagia, lo sai. Per quanto riguarda la sicurezza, in particolare.

— mirabilos,

@mirabilos È pericoloso solo se il gruppo o i flag di scrittura generali sono attivi. Il rischio con setuid è che chiunque disponga delle autorizzazioni di scrittura per il file possa eseguire tutto ciò che gli piace, come se fosse l'utente, e quindi sono queste autorizzazioni di scrittura che devono essere protette. 4755significa sempre eseguito come proprietario, il proprietario può leggere, scrivere ed eseguire, il gruppo può leggere ed eseguire e gli utenti possono leggere ed eseguire, che è il livello di autorizzazione standard per le cose che qualsiasi utente dovrebbe essere autorizzato a fare con le autorizzazioni di root.

— AJMansfield

@mirabilos E l'idea che gli script di shell con setuid introducano più vulnerabilità dei binari con setuid è semplicemente stupida; neanche i binari sono immuni all'exploit ptrace, che è l'exploit principale che sfrutta il setuid.

— AJMansfield

2

Tutti gli attuali sistemi operativi simili a Unix vietano gli script setuid. Questo è solo un dato di fatto. Chiedi loro delle ragioni se non mi credi. Inizia con OpenBSD.

— mirabilos,