Utilisation de sudo dans un script en arrière plan

Programmation
#1

Bonjour à tous,

J’utilise le logiciel backuppc et je l’ai configuré de manière à lancer un script avant de sauvegarder un poste.
Dans ce script, je dois donner des droits supplémentaires à l’utilisateur afin de lancer une commande particulière.
Je me suis donc penché sur sudo.
Mon script BASH fonctionne correctement dans un environnement classique, le problème est que lorsqu’il est lancé en arrière plan par le logiciel backuppc il ne fonctionne plus correctement et à besoin d’un TTY.

Voici l’erreur :

Mon fichier sudoers permet à l’utilisateur de ne pas donner de mot de passe pour effectuer la commande.

J’ai fait un certain nombre de recherches sans succès concernant le sujet, je suis surtout tombé sur le fait qu’il faille désactiver l’option requiretty mais elle est pas défaut désactivée sous debian.

Avez-vous déjà rencontré ce genre problème ?
Pourriez-vous m’aiguiller sur une piste ?
Est-il tout simplement impossible d’utiliser sudo de cette manère ?

Merci d’avance,

#2

Personnellement j’utilise super plutôt que sudo pour les cas comme ça où je veux pouvoir donner des droits différents à une commande particulière sans avoir à saisir de mot de passe. Je le trouve beaucoup plus simple à configurer que sudo, et le résultat est le même…

La seule caractéristique de super qui soit réellement différente de sudo c’est qu’il ne demandera jamais un mot de passe. À utiliser avec précaution et parcimonie, donc (mais bien entendu il fonctionne sur un principe de liste blanche, seules les commandes configurées dans /etc/super.tab seront prises en compte).

On peut aussi, entre autres possibilités, restreindre l’utilisation d’une commande à un utilisateur (ou groupe) donné, lancer la commande en question avec les droits d’un utilisateur autre que root, j’en passe et des meilleures.

#3

Super est quand même plus facilement exploitable par un mal intentionné : accès plus facile à la liste blanche.
Alors que pour “ouvrir” sudo, il faut se connecter en tant que root pour aller dans le sudoers.

#4

Merci pour vos réponses, je ne connaissais pas super et effectivement pour exécuter une commande en particulier il est intéressant d’une manière fonctionnelle.
Mon problème, pour ce script, est que j’ai besoin d’être dans l’environnement d’un utilisateur pour l’exécution d’une commande, c’est pourquoi j’utilisais sudo pour lancer la commande en tant que.
Mais je pense que je vais peut être me tourner vers une solution différente pour contourner le problème.

#5

Salut,

Pour utiliser un script en arrière plan nécessitant des droits “root” j’accorde à l’utilisateur, qui a un VRAI mot de passe, le droit d’exécuter cette commande en NOPASSWD :slightly_smiling:
Je n’ai rien trouvé de moins scabreux :mrgreen:

#6

[quote=“ricardo”]Super est quand même plus facilement exploitable par un mal intentionné : accès plus facile à la liste blanche.
Alors que pour “ouvrir” sudo, il faut se connecter en tant que root pour aller dans le sudoers.[/quote]
En quoi est-ce qu’éditer /etc/super.tab (qui est modifiable uniquement par root) est plus facile que d’éditer /etc/sudoers (qui est modifiable uniquement par root) ? :033

#7

Oui, c’est ce que j’ai fait.

sudo -u user "commande"
#user ayant des droits particuliers

Et dans le fichier sudoers, le groupe auquel appartient l’utilisateur backuppc a l’option NOPASSWD.

#8

Saluts,

Pour l’heure, inconnu … mais !

Intéressant ce “Super” paquet, en espèrent que le man soit en fr … :mrgreen:

#9

[quote=“syam”][quote=“ricardo”]Super est quand même plus facilement exploitable par un mal intentionné : accès plus facile à la liste blanche.
Alors que pour “ouvrir” sudo, il faut se connecter en tant que root pour aller dans le sudoers.[/quote]
En quoi est-ce qu’éditer /etc/super.tab (qui est modifiable uniquement par root) est plus facile que d’éditer /etc/sudoers (qui est modifiable uniquement par root) ? :033[/quote]
Je reconnais que tu as raison :blush:

EDIT :
Quoi que …
Si on part du principe que MDP user est en “béton” et que MDP root est en “béton armé”,
ET
que ‘sudo’ est ouvert à ALL pour user (si, c’est fréquent :smiley: )
THEN
il est plus facile de modifier le fichier /etc/super.tab (sudo nano …) : MDP béton
que de modifier sudoers, lequel ne peut l’être qu’en tant que root et non avec sudo : MDP béton armé.

#10

Pour information, j’ai résolu mon problème en passant par l’outil expect http://en.wikipedia.org/wiki/Expect.
J’ai pu ainsi me connecter sur le user en question et effectuer les commandes nécessaires sans problèmes.

#11

Comme je suis curieux de nature (et puis au moins aussi têtu que toi, ce qui n’arrange rien :wink:), j’ai installé sudo rien que pour tester…

[code]$ sudo nano /etc/sudoers
[sudo] password for syam:
$ sudo cat /etc/sudoers

This file MUST be edited with the ‘visudo’ command as root.

Please consider adding local content in /etc/sudoers.d/ instead of

directly modifying this file.

See the man page for details on how to write a sudoers file.

Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Host alias specification

User alias specification

Cmnd alias specification

User privilege specification

root ALL=(ALL:ALL) ALL

Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL

See sudoers(5) for more information on “#include” directives:

#includedir /etc/sudoers.d

AJOUTÉ AVEC sudo nano /etc/sudoers !!![/code]

Conclusion : je maintiens ce que j’ai dit, c’est exactement pareil. :smiley: [size=75]Et je désinstalle sudo de ce pas.[/size]

#12

Ben en effet, tu as raison :confused:
J’étais persuadé que c’était impossible … ou ça l’était avant ou j’ai rêvé ça ???

#13

Comme je suis curieux de nature (et puis au moins aussi têtu que toi, ce qui n’arrange rien :wink:), j’ai installé sudo rien que pour tester…

[code]$ sudo nano /etc/sudoers
[sudo] password for syam:
$ sudo cat /etc/sudoers

This file MUST be edited with the ‘visudo’ command as root.

Please consider adding local content in /etc/sudoers.d/ instead of

directly modifying this file.

See the man page for details on how to write a sudoers file.

Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Host alias specification

User alias specification

Cmnd alias specification

User privilege specification

root ALL=(ALL:ALL) ALL

Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL

See sudoers(5) for more information on “#include” directives:

#includedir /etc/sudoers.d

AJOUTÉ AVEC sudo nano /etc/sudoers !!![/code]

Conclusion : je maintiens ce que j’ai dit, c’est exactement pareil. :smiley: [size=75]Et je désinstalle sudo de ce pas.[/size][/quote]

Dommage de ne pas voir les deux “Defaults” préconisés sur ce forum et sécurisant sudo :laughing: :laughing: :laughing: :laughing:

#14

Si tu parles de ceci…

… alors il va falloir m’expliquer en quoi ça influe sur l’édition du sudoers. :wink:

D’autant que, tu le sais farpaitement car on en a déjà discuté longuement, je n’utilise pas sudo en temps normal. :smiley:

[quote=“syam”]j’ai installé sudo rien que pour tester…
[…]
[size=75]Et je désinstalle sudo de ce pas.[/size][/quote]