Discussion :

[devloPoint]

Bonjour,

Je n'arrive pas à modifier la crontab à partir de mon script python (J'utilise python 2 sous Raspbian Wheezy, mon utilisateur est "pi") :

#J'ai installé : pip install python-crontab

#Ceci est un exemple : Mon script s'exécute à 12h grâce à la crontab (configurée hors script). Puis dans ce script, je veux modifier la crontab afin de relancer ce même script à 14 heure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
from cron import CronTab
users_cron = CronTab(user='pi')
job = cron.new(command='/home/pi/Desktop/test.py') #Je veux exécuter ce script
job.hour.on(14)     # Je veux l'exécuter à 14h
job.enable()

#Une fois le programme quitté, je vérifie dans la crontab s'il y a eu la modification avec "crontab -e"....Mais non :-(

J'ai essayé pleins de variantes ou tuto mais je n'arrive pas à trouver ce qui ne va pas.

Merci pour votre aide

[wiztricks]

Salut,

Le script a-t-il été lancé via sudo?

- W

[devloPoint]

Salut :-)

Oui je lance bien mon script via sudo lorsque je le lance grâce à cron.

Après, lorsque je fais des tests, juste pour voir si la crontab est modifiée,
je lance le script manuellement via interface graphique, donc je ne suis pas en root.

Après, que ce soit en root ou non, dans le code que j'ai donné, il me dit que 'cron n'est pas défini'
au niveau de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

job = cron.new(command='/home/pi/Desktop/test.py') #Je veux exécuter ce script

Je ne sais pas comment l'initialiser ou s'il le faut d'ailleurs.

- J

[wiztricks]

Après, que ce soit en root ou non, dans le code que j'ai donné, il me dit que 'cron n'est pas défini'
au niveau de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

job = cron.new(command='/home/pi/Desktop/test.py') #Je veux exécuter ce script

Si le script plante, normal qu'il ne modifie pas la crontab.
Ajoutez "import cron" à la première ligne.

- W

[VinsS]

Salut,

J'utilise une ancienne version, donc vérifie l'import.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
from crontab import CronTab
 
tab = CronTab()
 
# Exemple
date = (12, 5, 8, 30)   # 12 mai 8:30
tab.dom().on(date[0])
tab.month().on(date[1])
tab.hour().on(date[2])
tab.minute().on(date[3])
 
tab.write()
 
# Exemple 2
date = (3, 10, 10)  # Tous les mercredis à 10:30
tab.dow().on(date[0])
tab.hour().on(date[1])
tab.minute().on(date[2])
 
tab.write()

Je remarque que j'ai utilisé ceci dans mon code, j'ignore si c'est toujours justifié, mais je le met à tout hasard:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
    def _write(self):
        def write(*args):
            self.tab.write()
 
        # To avoid an 'error: (4, 'System call interrupted')' the crontab
        # must be created in separate process
        Thread(target=write, args=(None,)).start()

Et NUL besoin de droits root pour crontab.

[devloPoint]

Wiztricks : Pour 'import cron', il ne connait pas ce module
VinsS : Pour ton code, j'ai un message d'erreur me disant que CronTab n'a pas d'attribut hour, month...

Je penses que je ne dois pas avoir la bonne bibliothèque.

J'ai trouvé une solution provisoire avec la création d'un fichier crontab temporaire que j'arrive à réinsérer dans la crontab.
C'est un peu plus lourd en code mais je dois avancer, c'est pour le travail (et ils m'attendent ;-))))

Merci à vous deux

[Sve@r]

Et NUL besoin de droits root pour crontab.

Bonjour

Ca dépend si on veut modifier son cron (dans ce cas effectivement la commande "crontab" fait la modif pour le compte de l'user qui la lance), ou celui d'un utilisateur X (ce qui devient alors une tâche d'admin que seul root peut exécuter).
Comme le code de devloPoint indique users_cron = CronTab(user='pi'), on peut penser qu'il veut modifier le cron de l'user "pi" (sinon je pense qu'il aurait utilisé le LOGNAME)...

[wiztricks]

Salut,

Wiztricks : Pour 'import cron', il ne connait pas ce module

Si "import cron" ne fonctionne pas, alors la première ligne de votre script "from cron import CronTab" devrait aussi planter et les messages d'erreurs de Python sont suffisamment bavards pour que vous ne passiez pas à côté. Et joindre ces indications à la description de vos problèmes serait une bonne habitude pour qu'on évite de perdre son temps (et vous aider plus rapidement).

- W

[VinsS]

Bonjour

Ca dépend si on veut modifier son cron (dans ce cas effectivement la commande "crontab" fait la modif pour le compte de l'user qui la lance), ou celui d'un utilisateur X (ce qui devient alors une tâche d'admin que seul root peut exécuter).
Comme le code de devloPoint indique users_cron = CronTab(user='pi'), on peut penser qu'il veut modifier le cron de l'user "pi" (sinon je pense qu'il aurait utilisé le LOGNAME)...

cron = tâche admin
crontab = tâche utilisateur

Le PO désire créer une tâche utilisateur, donc pas de 'sudo' ou autre.

Et évidemment on écrit pas un code lancé par un cron (donc avec les droits) qui créerait une tâche crontab nécessitant elle aussi des droits d'admin en espérant que cela passera.

Ça ne passera pas.

[devloPoint]

Salut,



Si "import cron" ne fonctionne pas, alors la première ligne de votre script "from cron import CronTab" devrait aussi planter et les messages d'erreurs de Python sont suffisamment bavards pour que vous ne passiez pas à côté. Et joindre ces indications à la description de vos problèmes serait une bonne habitude pour qu'on évite de perdre son temps (et vous aider plus rapidement).

- W

En fait, j'ai mal recopié le code :
c'était "from crontab import CronTab" et non "from cron...".

Je reviendrai plus tard, il faut vraiment que j'avance, je vais donc me contenter de ma solution provisoire. Je posterai les messages d'erreur et le code plus tard, là c'est un peu embêtant pour les copier/coller car mon Raspberry n'est pas en réseau et je ne poste pas depuis celui-ci.

Merci

[VinsS]

Wiztricks : Pour 'import cron', il ne connait pas ce module
VinsS : Pour ton code, j'ai un message d'erreur me disant que CronTab n'a pas d'attribut hour, month...

C'est pourtant ce que tu mets dans ton code original:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
job.hour.on(14)     # Je veux l'exécuter à 14h

Par contre tu sembles oublier le .write() .....


Edit: Vu le code source, ces méthodes sont devenues des @property, donc s'utilisent sans parenthèses.

http://bazaar.launchpad.net/~doctorm...ad:/crontab.py

[devloPoint]

Bonjour,

pour ceux que ça intéresse, voici ma solution (quelque peu détournée)

Je créé un fichier en y copiant la crontab de root :

sudo crontab -l -u root > /chemin_fichier

Je supprime la commande cron à la fin de ce fichier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import crontab
 
#On créé un fichier temporaire crontab_temp à partir du fichier précédemment créé:
shutil.copyfile('chemin_fichier_source', 'chemin_fichier_temporaire')
 
#On créé une commande cron :   
commande_cron = "* */10 * * * sudo reboot\n" #Ne pas oublier \n à la fin pour toute commande !
 
#On ajoute la commande de planification à la fin de crontab_temp
with open("/chemin_fichier_temporaire", 'a+') as file:
    text = file.read()
    file.write(commande_cron)
 
#On insère la commande du fichier temp dans la crontab :
os.system("sudo crontab /chemin_fichier_temporaire") #sans 'sudo' -> crontab de pi
#Je supprime le fichier temporaire
os.remove('/chemin_fichier_temporaire')

A+

[VinsS]

Salut,

Ben, c'est pas bon du tout ça.

Les tâches administrateur requièrent cron pas crontab, ce sont deux choses différentes.

Jamais de sudo avec, ni dans, crontab, c'est une faille de sécurité, n'importe qui peut entrer crontab -e et modifier la commande.

[Sve@r]

Les tâches administrateur requièrent cron pas crontab, ce sont deux choses différentes.

Pour moi ça va ensemble. "crontab" est la commande permettant d'éditer son fichier de configuration "cron"...

Jamais de sudo avec, ni dans, crontab, c'est une faille de sécurité, n'importe qui peut entrer crontab -e et modifier la commande.

En fait, celui qui fait crontab -e ne va modifier que son propre fichier ce qui restreint un peu les risques (impossible à Paul d'aller modifier le cron de Jacques). Mais sinon je suis d'accord, mettre un sudo c'est ouvrir une porte et vaut mieux alors réfléchir lonquement sur ce qu'on peut trouver derrière la porte

[devloPoint]

Pour moi ça va ensemble. "crontab" est la commande permettant d'éditer son fichier de configuration "cron"...


En fait, celui qui fait crontab -e ne va modifier que son propre fichier ce qui restreint un peu les risques (impossible à Paul d'aller modifier le cron de Jacques). Mais sinon je suis d'accord, mettre un sudo c'est ouvrir une porte et vaut mieux alors réfléchir lonquement sur ce qu'on peut trouver derrière la porte

Concernant le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

os.system("sudo crontab /chemin_fichier_temporaire") #sans 'sudo' -> crontab de pi

En fait, j'utilise "sudo crontab" car mon programme se lance au démarrage du Pi grâce à rc.local, donc le programme est lancé en root. Si je ne mets pas sudo, le fichier temporaire n'est pas copié dans la crontab de root...
Mais je ne vois pas quel est le problème de mettre sudo avant la commande ? quelle faille ça représente ? Ce n'est pas une affirmation mais bien une question ;-) ?

[Sve@r]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

os.system("sudo crontab /chemin_fichier_temporaire") #sans 'sudo' -> crontab de pi

En fait, j'utilise "sudo crontab" car mon programme se lance au démarrage du Pi grâce à rc.local, donc le programme est lancé en root. Si je ne mets pas sudo, le fichier temporaire n'est pas copié dans la crontab de root...

Bizarre car tu dis que ce programme se lance en root mais tu es obligé de faire un "sudo" (sous-entendu "sudo root") pour qu'il fonctionne. T'es sûr qu'il se lance en root ???

Mais je ne vois pas quel est le problème de mettre sudo avant la commande ? quelle faille ça représente ? Ce n'est pas une affirmation mais bien une question ;-) ?

Toute ouverture root est un risque. C'est le postulat par défaut que tu dois adopter si tu veux avoir un système toujours sécurisé. Maintenant tout risque ne se conclut pas forcément par l'ouverture de ton OS. Si tu es sûr de ton script, de ses droits (ainsi que des droits du dossier qui le contient) alors pas de souci. Mais c'est un réflexe que tu dois avoir si tu veux être tranquille. Imagine que le dossier soit en 777 (rwxrwxrwx) et ton script en 444 (r--r--r--) ben étant donné que le script est en "r" je peux le lire et donc le copier chez-moi. Chez-moi je peux le modifier. Comme le dossier est en "w" je peux effacer ton script d'origine et mettre le mien à la place (cette opération ne prend en compte que les droits du dossier et pas les droits du fichier). Et voilà comment je suis rentré dans ton OS !!!

D'ailleurs voici un exemple vécu (d'aujourd'hui): on m'a donné un compte sur une machine où je ne suis pas admin. Mes premières commandes ont été de répertorier les dossiers de l'arborescence où je peux écrire. J'en ai totalisé dans les 300. Puis j'ai répertorié les fichiers que je pouvais modifier. j'en ai totalisé plus de 16000. Donc déjà, à ce stade, je peux bouziller cette machine.
Mais ce n'est pas fini. je suis ensuite allé dans son site web (/var/www). Là, tous les dossiers et fichiers sont en 777. Je suis descendu dans un dossier de paramétrage de MySQL et j'ai récupéré le fichier nommé "config_inc.php", lequel contient le login+mot de passe d'accès au serveur de bdd MySQL. Donc maintenant j'ai un accès d'administrateur dans une base de données de production. Je peux t'assurer que quand je ferai mon rapport sur ce que j'ai fait, il y a un admin qui va se faire ouiner dessus...
Et en plus dans le dossier "/etc/httpd" (config d'apache), j'ai trouvé des listes de users avec leurs mots de passe (dont une ligne conteannt "root"). Ok il semble que ce soient des mots de passe cryptés (parce que j'ai essayé un "su") mais si je trouve le script qui créé ce fichier et l'algo de chiffrement ça sera jackpott !!!

Donc pour répondre à ta question, c'est rarement une faille qui gêne. C'est plutôt l'accumulation d'une faille X et d'une faille Y et d'un manque de réflexion sur le vrai besoin de mettre ces failles...

[devloPoint]

Sve@r,

Ok je comprends mieux ce que tu veux dire et tes exemples sont très parlant. Je ferai attention aux droits de mes dossiers, scripts et à l'emploi du sudo... Mais après je n'y ai pas trop fait attention car il n'y aura que l'administrateur de la machine qui aura un compte. Donc je suppose que ça ne pose pas de problèmes ?

Après, pour répondre à ton interrogation sur le rc.local et le script exécuté en root au démarrage. En fait, si je fais un "crontab" et pas un "sudo crontab", c'est la crontab de l'utilisateur 'pi' (qui est mon unique user) qui est mise à jour et non celle de root. Il n'y qu'en passant par ce sudo que j'arrive donc à plannifier une nouvelle tâche au démarrage...