Planificateur / Crontab En Root Uniquement ?

[Deadbone]

Bonjour,

Je suis tombé sur un problème assez gênant sur un DS713 avec le dernier DSM en date, ipkg fonctionnel.

Je cherche à programmer une tâche (script bash établissant une connexion ssh vers serveur distant via echange de clef, pour effectuer certaines taches sur ce serveur distant ) via le planificateur en précisant bien le USER concerné (qui est dans le groupe administrateur) .

Je me suis rendu compte que ma connexion était refusée suite à un problème de clef (alors que si je teste le contenu en ssh via le compte USER concerné depuis le SYNO, tout fonctionne parfaitement) ...

J'ai ajouté la commande "id" dans mon script pour vérifier quel était le USER qui était utilisé pour le lancement de la tâche... et au lieu de voir mon USER, je vois la mention "root"

J'ai édité le crontab, et effectivement, ce n'était pas le USER spécifié dans le planificateur mais le root. J'ai remplacé "root" par le USER en question, stoppé et relancé le cron avec les commandes dédiées... mais le problème subsiste.

Donc, dans mon cas, spécifier un USER spécifique dans le planificateur ou dans le crontab ne sert à rien : le root prend toujours la main.

Une solution rapide serait de créer des clefs SSH pour le root et d'apairer mon serveur distant, mais cela me plait moins que de comprendre l'origine du problème, et de le corriger

Si quelqu'un a une solution, une piste, je suis preneur

[CoolRaoul]

Les scripts définis par le planificateur de tache pour un autre utilisateur que "root" sont exécutés en mode suid/sgid (je viens de le découvrir moi aussi)

Tu n'a pas fait gaffe mais dans le résultat de ta commande "id", alors que uid vaut bien "root", la présence de "euid" correspondant au compte utilisateur effectif (et egid pour le groupe principal)

Un petit test me montre en outre que la variable HOME n'est pas présente dans l'environnement du job

Peut être que l'erreur vient en partie de là.

Tu peux essayer d'indiquer explicitement le chemin de ta clé privé en argument de la commande ssh (ssh -i <chemin de la clé)

Mais surtout, je préconise de mettre en début de ton script un truc du genre de:

if [ "$HOME" = "" ] ; then
    HOME=~<mettre_le_user_ici>
    export HOME
fi

Car l'absence de HOME ne peut que provoquer d'autre effets biens velus à débugger.

[Deadbone]

Merci pour ces pistes, je testerai (plutôt ta 2eme préconisation) ceci bientôt et ferai un retour ici.

[Deadbone]

de retour

voici la sortie de la commande id que j'avais mise dans mon script :

uid=0(root) gid=0(root) groups=100(users),101(administrators)

J'ai ajouté le path du home du USER desiré, mais pas de changement de comportement...

je vais donc essayé d'indiquer le chemin de la clef

[CoolRaoul]

de retour

voici la sortie de la commande id que j'avais mise dans mon script :

uid=0(root) gid=0(root) groups=100(users),101(administrators)

C'est tres surprenant

Voici ce que ca donne pour moi:

uid=0(root) gid=0(root) euid=1032(clampin) egid=100(users) groups=100(users),65540(localusers),65541(people),65553(photo_r)

Vu que tu utilises bash, peut-être qu'il intègre une commande "id" en builtin avec un comportement différent.

Essaie de forcer la commade "id" externe (en mettant explicitement le path complet: /usr/bin/id)

Autre piste (me semble plus probable): j'ai mis ma commande "id" directement dans le champ "script défini par l'utilisateur" de déclaration de tache. Fort possible que l'appel d'un script externe (et donc un sous-shell) fasse perdre le contexte suid.

Modifié le 9 décembre 2013 par CoolRaoul

[Deadbone]

effectivement, l'appel à "id" directement dans le champ du planificateur donne bien une ligne comme la tienne :

uid=0(root) gid=0(root) euid=1026(clampin2) egid=100(users) groups=100(users),101(administrators)

(mon user a les droits admin)

[Deadbone]

En revanche, dans mon script,

/usr/bin/id >> $FICHIER

echo "*******" >> $FICHIER

id >> $FICHIER

donne la même chose quand je "force" l'exécution du script via le DSM loggé avec le user en question et le script prévu pour être lancé avec cet utilisateur ...

sortie :

uid=0(root) gid=0(root) groups=100(users),101(administrators)
*******
uid=0(root) gid=0(root) groups=100(users),101(administrators)

​Je vais donc tester la spécification du chemin de la clef dès que je pourrai (le syno n'est pas très waf )

[CoolRaoul]

Il faut donc retenir de tes expériences que, dans le cas d'une tache pour un compte "non root", seule les commandes saisies dans le formulaire vont effectivement s'exécuter pour le compte utilisateur donné en mode "suid".
Tout script externe sera exécuté en tant que root.

Dans ce contexte, peut-être vaut-il-mieux finalement affecter la tache au compte root et invoquer le script ainsi:

/bin/su -s /bin/ash -c "<chemin_complet_du_script>" - <compte_cible>

Ca sera plus propre. (attention a ce que le script soit lisible et exécutable par le compte cible)

[Deadbone]

Merci pour ces précisions... je me rends compte que je suis un peu léger sur certaines commandes / notions de droits ...

Je teste ce soir

Et merci pour avoir passé du temps sur cette problématique

[CoolRaoul]

Merci pour ces précisions... je me rends compte que je suis un peu léger sur certaines commandes / notions de droits ...

Oh tu sais, on en apprend tout le temps!

Par exemple, la façon "shadok" dont le planificateur de tache lance des jobs non root je l'ai découvert grâce à toi.

[Deadbone]

Merci CoolRaoul,

/bin/su -s /bin/ash -c "<chemin_complet_du_script>" - <compte_cible>

me permet de lancer mes scripts !

je ne vois pas comment faire pour mettre ce thread en "résolu" …