Les utilisateurs de base de DTC (pas root), ont accès a un espace très limités en accès /bin, on peut faire un chroot sur cet environnement, mais on en peut pas alors installer de paquets (j’ai bien essayé de copié un maximum de fichiers pour que dpkg se débrouille mais ça coince toujours) , donc je me suis dit que je devrais faire un script qui commanderais à root de faire quelques tâches.
Le principe serait que se script modifie l’état d’un fichier texte, et que la modification de ce fichier entraîne root à faire “# python +contenu_du_fichier_texte”, l’idéal serait que le résultat de la console s’affiche également … Possible ?
Le problème c’est que l’utilisateur ne voit pas les exécutables, ils sont en dehors du chroot, c’est pour ça qu’un fonctionnement comme sudo n’est pas possible de toute façon !
Tu veut pouvoir faire quoi exactement ? Si tu as besoin d’un ou deux programme tu dois pouvoir simplement écrire des programmes en executables linkés statiquement, sinon tu as toujours la possibilité d’utiliser bootstrap pour installer une debian dans ton chroot.
Je veux que l’utilisateur du chroot puisse exécuter des commandes depuis le root de l’environnement principal (hors chroot)
L’un des principes du chroot c’est justement d’éviter ça (bien que ce n’est pas aussi poussé que les jails). Néanmoins mon esprit torturé à une idée :
Tu défini un fichier dans ton chroot par exemple /cmd.
Un utilisateur écris la commande dans ce fichier
Auparavant, dans le système hote, tu utilise inotify (ou dnotify) pour surveiller les modifications de ce fichier et tu les exécute en root (tu peut envoyer le résultat de la commande dans un autre fichier).
Voila, c’est ce genre de chose que je voulais, c’est quand même pas sorcier non !!!, enfin un peut de réflexion, c’est trop demandé … ?
PS : Je plaisante, c’est pour ton côté névrosé que je titille 
merci beaucoup !
Fais quand même gaffe à la sécurité de ton truc parce que comme je l’ai mis, une mauvaise manipulation est vite arrivée.
Si tu veut un coup de main pour inotify n’hésite pas, j’ai un long week end devant moi 
En fait je veux le limiter à des actions python, le contenu du fichier sera exécuté avec comme préambule “python” et le chemin fixe du dossier chrooter, je pense pouvoir éviter la plupart des trous.
et si c’est bien un script python qui fait appel a une instruction système ? là je pense que ça va faire mal.
Pour des raisons de sécurité j’éviterai ce mode de fonctionnement.
En fait à bien y réfléchir il n’y a que deux commandes dont j’ai besoin :
python manage.py runserver
python manage.py syncdb
Et j’essaye de mon côté, mais je bulle … impossible de comprendre comment on utilise inotify !
Misterfreeze t’as un moment pour me mâcher le boulot ?
Au pire tu fais un script qui regarde de temps en temps (avec un cron) le contenu du fichier si tu n’a pas besoin d’un truc immédiat. ça évitera aussi une attaque par changement perpétuel du contenu du fichier
Non, justement j’ai besoin que ce script s’exécute “à la demande” …
[quote=“debianhadic”]En fait à bien y réfléchir il n’y a que deux commandes dont j’ai besoin :
python manage.py runserver
python manage.py syncdb
Et j’essaye de mon côté, mais je bulle … impossible de comprendre comment on utilise inotify !
Misterfreeze t’as un moment pour me mâcher le boulot ?[/quote]
Ce soir ou demain soir désolé.
Si tu as un nombre de commande limité peut être que Launch and forget te serais utile :
linuxfr.org/~tchetch/30038.html
Mais du coup tu peut pas le faire avec un navigateur.
J’ai pas le temps de te coder un truc en python avant mon cours (dans 6 minutes), mais tu peut trouver un tuto en C ici :
julp.developpez.com/linux/inotify/
Je voyais plus un truc genre shell …
Tu fais un programme qui lis les commandes dans un tube et les exécute (racine principale) et un autre qui met les commandes dans le tube.
Les droits à gérer sont ceux qui écrivent dans le tube.
Tu n’as pas a te préoccuper de voir si un fichier est modifié, le tube (pipe) est fait pour ça, et dès que la commande est écrite, elle est éxécutée.
Hum … Exemple ?
Bonjour,
Comme l’a dit fran.b, le mieux est d’exploiter les tubes.
Script “root” :
#!/bin/bash
[ ! -p <dossier_chroot>/.montube ] && mkfifo <dossier_chroot>/.montube
while read
do
tty="${REPLY%%:*}"
cmd="${REPLY#*:}"
eval "${cmd} > ${tty}" &
done < <dossier_chroot>/.montubeScript “utilisateur” :
#!/bin/bash
[ ! -p <dossier_chroot>/.montube ] && mkfifo <dossier_chroot>/.montube
echo "$(tty):python $1" > <dossier_chroot>/.montube
A utiliser comme ceci coté utilisateur :
nomscript “commande python”
Le script “root” est une sorte de démon… il faut donc qu’il soit lancé au démarrage du système (par exemple)
Il est possible qu’il y ait des ajustements à faire (pas testé)
même remarque me concernant : vraiment pas top coté sécurité
il faudrait ajouter des controles coté serveur pour vérifier les commandes autorisées
Trè bonne idée le coup du fifo !
Par contre je ferrais plutôt ça. En root :
[ !-p "$CHROOT/fifo" ] && mkfifo $CHROOT/fifo
while read id do
if [ "$id" == "1" ]; then
cmd1 > $CROOT/res &
elif [ "$id" =="2" ]; then
cmd2 > $CROOT/res &
else
echo "Inconnu : $id" > $CHROOT/res &
fi
done < $CHROOT/fifo
rm $CHROOT/fifo
[ -f "$CHROOT/res" ] && rm "$CHROOT/res"
Ainsi aucun risque de sécurité. Dans le chroot tu écris 1 ou 2 dans le fichier /fifo et la commande résultante est executée. Le résultat de la commande est dans /res.