Le fichier init dans les appels init.d à l'aide de sudo dans script.sh donne une erreur sudo: aucun tty présent ni programme askpass spécifié

J'essaie de créer un script qui démarre au démarrage pour se connecter à mon VPN personnel.

J'ai un fichier d'initialisation: /etc/init.d/vpnstartup

qui appelle mon script vpnon.sh au démarrage avec les commandes:

case "$1" in
    start)
        su username -c $VPN_DIR/vpnon.sh
        ;;

dans mon script vpnon.sh, certaines commandes nécessitent l'exécution d'autorisations root:

sudo iptables -A INPUT -i pptp -j ACCEPT
sudo iptables -A OUTPUT -o pptp -j ACCEPT

J'accorde les autorisations du fichier vpnstartup init et du script vpnon.sh avec chmod 775 lorsque j'essaie mon fichier init en l'appelant à l'aide de ./vpnstartup start

J'obtiens l'erreur suivante lorsque la commande sudo iptables est appelée

sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified

Ce que je pense, c'est que la commande sudo nécessite un mot de passe, mais ne permet pas de l'obtenir.

La seule solution que j'ai trouvée a été d'ajouter le NOPASSWD :ALL option fichier au fichier sudoers sous mon nom d'utilisateur.

Pour des raisons de sécurité, je ne souhaite pas utiliser cette méthode s'il existe une meilleure solution.

S'il vous plaît laissez-moi savoir si vous pouvez m'aider avec ce problème; J'ai passé de nombreuses heures dessus.

Je pense que l'un des facteurs clés ici est que, comme un script est exécuté avec sudo, il peut faire tout ce que root peut faire. Le problème est que les autres commandes sudo de ce script n'héritent pas nécessairement des droits d'accès root, mais sont exécutées en tant qu'utilisateur contrôlant. Cela peut souvent produire l’erreur que vous voyez de sudo, même si le script parent lui-même est autorisé via sudo mais que les sous-commandes ne le sont pas.

Ce qui se passe, c’est que l’appel sudo imbriqué dans ce script échoue car sudo devrait normalement demander un mot de passe, mais il n’existe aucun shell de contrôle qui le permette. Cela génère l' sudo: no tty present and no askpass program specifiederreur légèrement ambigu que vous voyez.

Un moyen simple d’illustrer ceci est si, comme dans votre exemple, un script init contient des appels internes utilisant sudo. Fonctionnement:

sudo /etc/init.d/startvpn

peut échouer si votre propre utilisateur ne dispose pas des droits sudo sur tous les appels sudo au sein de celui-ci et risque de vous donner l'erreur sudo tty. Cependant, l'exécuter comme ceci:

sudo sh /etc/init.d/startvpn

fonctionnerait probablement. Dans ce dernier cas, sudo shun shell de commande est créé en tant que root. Par conséquent, tout ce qui est exécuté dans ce shell est exécuté en tant que root. Root dispose généralement d'autorisations sudo illimitées, il n'est donc plus important si une commande est exécutée avec sudo ou non.

Quelques points à noter:

• Comme d'autres l'ont fait remarquer, il est possible d'éviter ce désordre en évitant d'utiliser sudo dans les scripts. Souvent, les sous-commandes qui échouent lorsqu'elles sont exécutées avec sudo peuvent fonctionner correctement sans cette opération (lorsque le script parent est exécuté avec sudo).
• Le fait d’exécuter le script avec sudo shpeut résoudre le problème, mais cela entraîne également des problèmes de sécurité. Considérez que sudo se comporte de cette manière comme une vérification de cohérence, afin de s’assurer que le contenu du script ne fait pas ce qu’il ne devrait pas, même si le script lui-même est autorisé.
• Si l'utilisateur sur lequel vous exécutez sudo dispose également d'autorisations d'accès suffisantes, vous risquez de ne rencontrer aucun de ces problèmes. Mais ils peuvent apparaître plus tard, par exemple, si vous développez un script avec votre propre compte privilégié et qu’il est exécuté en production en tant que compte de service non privilégié.
• En règle générale, évitez d’accorder des autorisations générales sudo aux comptes d’utilisateur pour résoudre ce type de problème. Si cela est vraiment nécessaire, limitez les règles d'accès au compte à cet utilisateur et à cette commande spécifique.

J'ai trouvé la solution au problème.

J'ai supprimé toutes les commandes sudo de mon script vpnon.sh et les ai passées dans sudo de l'extérieur du script.

Dans mon fichier /etc/init.d/vpnstartup, j'ai changé su username -cà ce sudo $VPN_DIR/vpnon.sh qui ressemble à ceci maintenant:

case "$1" in
    start)
        sudo $VPN_DIR/vpnon.sh
        ;;

puis appelé sudo update-rc.d vpnstartup defaults et maintenant le VPN se connecte au démarrage!:)