Les scripts qui nécessitent sudo doivent-ils échouer s'ils ne l'ont pas, ou utiliser sudo et prompt?

26

J'ai un script qui me donne un contrôle fin sur la luminosité de mon rétro-éclairage et nécessite sudode s'exécuter. C'est essentiellement ceci:

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

et vit à ~/bin/backlight-adjust. Le script a besoin de sudoprivilèges, car il tee $backlightécrit dans un emplacement privilégié. Il échouera donc s'il n'est pas exécuté avec sudo.

Cette approche a un problème, parce que je ne peux pas simplement courir sudo backlight-adjust, parce que ce ~/binn'est pas $PATHdans l' sudoenvironnement, seulement dans mon environnement. Je devrais donc courir sudo env "PATH=$PATH" backlight-adjustou quelque chose de similaire.

Alternativement, j'aurais pu l'écrire comme ceci:

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

et me demander le mot de passe.

La deuxième approche fonctionne mieux pour moi car je n'ai pas à me rappeler de taper sudo; ça m'invitera. Et je peux garder mon $PATHintact. Cela semble plus pratique dans l'ensemble, mais y a-t-il des raisons pour lesquelles je ne devrais pas le faire de la deuxième façon?

(J'utilise Xubuntu 14.04 et mon shell est GNU bash 4.2.45, si cela fait une différence.)

bash shell-script sudo

— John Feminella
source

Merci pour la correction. J'utilise un Debian modifié (LMDE) et mon sudoconserve en fait mon $PATHpar défaut, donc je n'ai pas ce problème.

— terdon

27

Personnellement, j'utiliserais une approche différente. Créez un alias pour votre script. Ajoutez cette ligne à votre ~/.bashrc(ou équivalent dans d'autres shells)

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

De cette façon, vous n'avez pas à vous soucier de vous souvenir de l'exécuter avec sudoet vous n'avez pas besoin d'ajouter le sudoau script. Il sera complètement transparent pour vous et vous demandera simplement votre mot de passe lorsque vous essayez de courir backlight-adjust.

— terdon
source

Cela semble être une approche très sensée, et celle ayant un impact minimal sur le reste du système. +1.

— John Feminella

@JohnFeminella D'un autre côté, si vous souhaitez partager ce script avec quelqu'un d'autre, il aura également besoin de l'alias. Personnellement, je ne vois aucune raison de ne pas mettre sudole script réel, d'autant plus que cela vous permet de voir facilement quels éléments du script nécessitent réellement des autorisations root.

— Kyle Strand

@KyleStrand non, ils ne le feront pas. La commande appelée par le script se plaindra simplement de ne pas y avoir accès.

— terdon

@terdon Je reconnais que j'aurais pu être un peu plus clair, mais vous savez probablement ce que je voulais dire: le destinataire du script sera confronté au même problème que celui rencontré à l'origine par l'auteur du script, et en tant que partage de script consciencieux, l'auteur devrait partagent également leur solution personnelle à ce dilemme d'utilisation particulier.

— Kyle Strand

@KyleStrand oui, mais il n'y avait pas de problème, le seul problème que l'OP avait était qu'il ne voulait pas "avoir à se rappeler de taper sudo" à part ça, le script sera parfaitement portable. Mon point est que l'alias est complètement facultatif et ne résout rien, il le rend simplement plus facile à utiliser.

— terdon

7

Je ne vois pas pourquoi cela pourrait être incorrect --- bien que je préfère normalement que les commandes ne me demandent rien, de sorte qu'elles soient scriptables. Vous pouvez modifier /etc/sudoerspour que cela sudofonctionne sans mot de passe.

Mais ... pourquoi ne pas ajouter

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

dans votre /etc/rc.localet oublier sudo?

(Dans Ubuntu, si vous pouvez l'utiliser, sudovous faites partie du groupe sudo , vous pouvez donc l'utiliser chgrp sudo /sys...et en être satisfait.)

— Rmano
source

3

Vous pouvez également ajouter

Defaults        env_keep +="PATH"

à votre /etc/sudoersdossier.

— Minou
source

2

Vous déclarez sudo-adjust, car ~ / bin n'est pas dans $ PATH dans l'environnement sudo

Alors pourquoi en dépendre? Je pense que vous devriez simplement changer cette ligne /home/user/bin/backlight-adjustet cela fonctionnera.

Mais j'aimerais vraiment que Terdon utilise également un alias. Ou vous pouvez placer votre script /usr/bin/et il sera disponible pour tous les utilisateurs (y compris root)

— ExploWare
source

Oui, mais c'est ennuyeux de le faire. Sinon, quel était l'intérêt de le mettre dans mon $ PATH en premier lieu? De plus, j'aime l'avoir, ~/bincar il se trouve dans le référentiel de fichiers dot de ma maison, il reste donc sous contrôle de version.

— John Feminella

@JohnFeminella au fait, il n'y a aucune raison de changer de chemin, il suffit d'utiliser le -Edrapeau pour préserver l'environnement:sudo -E command

— terdon

@terdon Cela ne fonctionne pas dans Debian; il est annulé pour des raisons de sécurité. Il faudrait passer explicitement les variables d'environnement, comme je l'ai mentionné dans ma question ( sudo env "PATH=$PATH" ...).

— John Feminella

1

Je ne peux pas donner de règle générale ... si le script / programme est conçu pour effectuer une reconfiguration (par exemple une imprimante) et être appelé par des utilisateurs réguliers, il doit le faire. Sinon, je laisserais assez bien seul: si un utilisateur régulier l'exécute, échouez (soit à la suite d'une vérification explicite, soit simplement parce qu'il n'est pas autorisé à faire quelque chose).

Des privilèges élevés devraient être accordés avec parcimonie, voire pas du tout. Passer à des privilèges plus élevés est délicat, mieux vaut le laisser aux experts (c.-à sudo(1)-d.).

— vonbrand
source

0

J'utilise personnellement quelque chose comme ${SUDO}dans mes scripts, afin que l'appelant puisse le définir si nécessaire, ou l' ${SUDO:-sudo}utiliser par défaut.

Dans votre cas particulier, je suis d'accord avec la réponse, cependant.

— mirabilos
source

-1

Placez le script (sans le sudo) dans un emplacement approprié à l'échelle de l'utilisateur, comme /bin, puis procédez comme suit:

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

Cela fonctionne en définissant l'indicateur setuid, ce qui signifie qu'il sera toujours exécuté en tant que propriétaire du fichier. Pour plus de détails, veuillez lire http://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/ . Je ne sais pas vraiment grand-chose sur la façon dont cela fonctionne, je l'ai juste trouvé googler sur la base de quelque chose que je pensais avoir lu il y a quelques années.

— AJMansfield
source

1

Les scripts shell ne peuvent plus être configurés, Dieu merci… C'est une réponse totalement diabolique, vous savez. Sur le plan de la sécurité, en particulier.

— mirabilos

@mirabilos Son seul danger si le groupe ou les drapeaux d'écriture générale sont activés. Le risque avec setuid est que toute personne disposant d'autorisations d'écriture pour le fichier peut exécuter tout ce qu'elle veut comme si elle était l'utilisateur, et ce sont donc ces autorisations d'écriture qui doivent être protégées. 4755signifie toujours exécuté en tant que propriétaire, le propriétaire peut lire, écrire et exécuter, le groupe peut lire et exécuter et les utilisateurs peuvent lire et exécuter, ce qui est le niveau d'autorisation standard pour les choses que tout utilisateur devrait être autorisé à faire avec les autorisations root.

— AJMansfield

@mirabilos Et l'idée que les scripts shell avec setuid introduisent plus de vulnérabilités que les binaires avec setuid est tout simplement stupide; les binaires ne sont pas non plus à l'abri de l'exploit ptrace, qui est le principal exploit qui tire parti de setuid.

— AJMansfield

2

Tous les systèmes d'exploitation de type Unix actuels interdisent les scripts setuid. C'est juste un fait. Demandez-leur vous-même des raisons si vous ne me croyez pas. Commencez avec OpenBSD.

— mirabilos