#1 Le 30/10/2015, à 23:03
- khabarakh
[RESOLU]script fonctionnel mais pas dans le crontab
Bonjour, j'ai un petit soucis , j'ai crée un script qui fonctionne quand je le lance en direct, mais quand je le lance depuis le crontab , il fonctionne à moitié, je m'explique.
#!/bin/bash
FOUND=`grep "tun0" /proc/net/dev`
TORRENT=`pgrep transmission`
if [ -n "$FOUND" ] ; then
echo "Vpn connecté" >> ~/vpnlog
if [ -n "$TORRENT" ] ; then
echo "toutroule" >>~/vpnlog
else
sudo /etc/init.d/transmission-daemon start
fi
else echo "pas de vpn connecté" >~/vpnlog
if [ -n "$TORRENT" ] ; then
sudo /etc/init.d/transmission-daemon stop
else
echo "2" >>~/vpnlog
fi
fi
voici le code en question. quand je le lance il lance ou coupe le daemon en fonction du résultat. mais depuis le crontab les echo apparaissent bien dans le fichier vpnlog mais la commande ne s'execute pas.
j'avoue ne pas comprendre pourquoi, si quelqu'un peut éclairer mon chemin se serait gentil.
d'avance merci.
Dernière modification par khabarakh (Le 31/10/2015, à 00:25)
Hors ligne
#2 Le 30/10/2015, à 23:12
- jplemoine
Re : [RESOLU]script fonctionnel mais pas dans le crontab
Je pense qu'il y a un soucis : comment tu peux avoir un sudo dans un script du crontab ? On ne peut pas saisir le mot de passe !!!!!
Il faut :
- forcer le chemin du fichier log
- virer le sudo
- le lancer dans le cron de root et non pas celui de l'utilisateur
Ce compte ne servira plus : vous pouvez le supprimer si le coeur vous en dit...
Laissé par l'auteur pour historique.
Hors ligne
#3 Le 30/10/2015, à 23:15
- khabarakh
Re : [RESOLU]script fonctionnel mais pas dans le crontab
non car le fichier appartient à root et le bit setuid est à 1 donc le script est fonctionnel.
Dernière modification par khabarakh (Le 30/10/2015, à 23:16)
Hors ligne
#4 Le 30/10/2015, à 23:58
- jplemoine
Re : [RESOLU]script fonctionnel mais pas dans le crontab
donc le script est fonctionnel.
Alors, il n'y a aucun problème.....
Ce compte ne servira plus : vous pouvez le supprimer si le coeur vous en dit...
Laissé par l'auteur pour historique.
Hors ligne
#5 Le 31/10/2015, à 00:01
- Postmortem
Re : [RESOLU]script fonctionnel mais pas dans le crontab
Salut,
Il me semble, je dis bien il me semble, que le setuid ne fonctionne pas/plus pour les scripts, une histoire de sécurité. Je ne suis pas du tout certain de ce que j'avance mais il me semble avoir lu ça il y a quelques temps.
Et puis si ça marchait le setuid, ton sudo serait inutile car le script serait exécuté en tant que root.
Ton script étant fait pour arrêter et démarrer quelque chose et que ce quelque chose nécessite les droits de root, tu devrais essayer de supprimer le sudo dans ton script et mettre ton script dans la crontab de root.
Mot' a dit : « Un Hellfest sans Slayer, c'est comme une galette-saucisse sans saucisse ! »
Hors ligne
#6 Le 31/10/2015, à 00:13
- khabarakh
Re : [RESOLU]script fonctionnel mais pas dans le crontab
tres bien je vais essayer cela, merci à vous deux.
edit: apres avoir passer le script sur le crontab de root, il s’exécute correctement.
Dernière modification par khabarakh (Le 31/10/2015, à 00:25)
Hors ligne
#7 Le 31/10/2015, à 09:42
- tiramiseb
Re : [RESOLU]script fonctionnel mais pas dans le crontab
Salut,
S'il y a le setuid, alors sudo est inutile. sudo te demandera le mot de passe quel que soit l'état du suid : il s'en fout. D'où la nécessité :
* soit juste de virer sudo su le suid fonctionne
* soit de virer sudo et de mettre ton script dans le crontab de root
Sébastien Maccagnoni - https://www.maccagnoni.eu - https://www.domotego.com
Hors ligne
#8 Le 31/10/2015, à 10:51
- Postmortem
Re : [RESOLU]script fonctionnel mais pas dans le crontab
J'ai retrouvé ça concernant le droit suid et les scripts :
Protection contre une attaque de type sushi Modifier
Sur linux, des restrictions de droit ont été faites sur le drapeau SUID :pour un fichier de script, l'exécution se fera sans tenir compte du drapeau SUID
Il semble de plus que si un utilisateur autre que le propriétaire modifie le fichier, alors le bit SUID est remis à 0.
Il n'est pas sûr que les versions d'Unix actuelles aient implémenté cette sécurité ; dans ce cas, cela ouvre la porte à une attaque qui est appelée sushi (su shell) : l'utilisateur root crée un fichier de shell avec le bit SUID en laissant les droits en écriture à d'autres utilisateurs ; l'un d'eux pourra modifier le fichier et exécuter tout ce qu'il voudra avec les droits de root.
Mot' a dit : « Un Hellfest sans Slayer, c'est comme une galette-saucisse sans saucisse ! »
Hors ligne
#9 Le 31/10/2015, à 10:53
- khabarakh
Re : [RESOLU]script fonctionnel mais pas dans le crontab
merci pour ces informations supplémentaire.
Hors ligne