Problème droits root et divers
Résolu
barnabe0057
Messages postés
17074
Statut
Contributeur
-
barnabe0057 Messages postés 17074 Statut Contributeur -
barnabe0057 Messages postés 17074 Statut Contributeur -
Bonjour bonne année à la communauté,
J'ai un script shell que je dois exécuter en root (à cause de la commande ufw) :
1) Si j'exécute le script manuellement (./ufw_conf.sh) depuis /root ça fonctionne, la création d'une nouvelle règle ufw fonctionne.
2) Si j'exécute le script depuis le crontab root (@reboot /root/ufw_conf.sh) le script est bien démarré :
mais il ne fonctionne pas (il ne crée pas de nouvelle règle ufw).
3) Si j'exécute le script depuis un utilisateur normal (/home/utilisateur/ufw_conf.sh) avec les droits root (permission spéciale u+s) le script démarre mais ne fonctionne pas.
Voilà la question : pourquoi dans le cas n°2 et n°3 ça ne fonctionne pas comme attendu ?
Je suis sur Debian "Jessie"
J'ai un script shell que je dois exécuter en root (à cause de la commande ufw) :
#! /bin/bash
COUNTER=0
fichier=/var/www/parefeu/ip_address.txt
# on crée une boucle infinie
while [ $COUNTER -eq 0 ]; do
# on vérifie si le fichier est vide ou pas
# methode alternative : test -s $fichier || continue
# methode alternative : grep ":" $fichier || continue
cat $fichier | grep ":" || continue
# on lit les infos dans le fichier texte
IFS=':' read -r adresse port <$1
# on crée une nouvelle règle
ufw allow in proto tcp from $adresse to any port $port
# on réinitialise le fichier texte
truncate -s 0 $fichier
# on recharge le pare-feu
ufw reload
done
1) Si j'exécute le script manuellement (./ufw_conf.sh) depuis /root ça fonctionne, la création d'une nouvelle règle ufw fonctionne.
2) Si j'exécute le script depuis le crontab root (@reboot /root/ufw_conf.sh) le script est bien démarré :
root@sd-18936:~# ps aux | grep "ufw" root 695 0.0 0.0 4340 720 ? Ss 11:25 0:00 /bin/sh -c /root/ufw_conf.sh root 710 0.1 0.0 13400 3208 ? S 11:25 0:02 /bin/bash /root/ufw_conf.sh root 18941 0.0 0.0 12756 2104 pts/0 S+ 12:08 0:00 grep ufw
mais il ne fonctionne pas (il ne crée pas de nouvelle règle ufw).
3) Si j'exécute le script depuis un utilisateur normal (/home/utilisateur/ufw_conf.sh) avec les droits root (permission spéciale u+s) le script démarre mais ne fonctionne pas.
Voilà la question : pourquoi dans le cas n°2 et n°3 ça ne fonctionne pas comme attendu ?
Je suis sur Debian "Jessie"
Configuration: Win 7 Pro SP1 64bits
Athlon X4 750K Quad Core
8 Go DDR3 1866 Mhz
Athlon X4 750K Quad Core
8 Go DDR3 1866 Mhz
A voir également:
- Problème droits root et divers
- Kingo root - Télécharger - Divers Utilitaires
- Supprimer application préinstallée android sans root - Guide
- Les textes ne doivent pas être en retrait à droite et à gauche - Guide
- Vous devez disposer des droits d'administrateur pour supprimer ce dossier - Guide
- Donnez à ce fichier les mêmes droits d'accès que les autres notes de service. ✓ - Forum Jeux vidéo
4 réponses
root a accès à /var/www ?
Sinon ajoute root au group www-data
Sinon ajoute root au group www-data
barnabe0057
Messages postés
17074
Statut
Contributeur
4 925
oui root a accès à /var/www puisque ça fonctionne si je lance le script manuellement (cas n°1)
cs_PaTaTe
Messages postés
2230
Statut
Contributeur
497
Il peut avoir les droits d'exécution mais pas d'écriture ^^
barnabe0057
Messages postés
17074
Statut
Contributeur
4 925
Ok j'ai rajouté root au groupe www-data, je vais tester.
barnabe0057
Messages postés
17074
Statut
Contributeur
4 925
Non ça ne marche pas toujours pas via crontab.
Salut,
Moi ce qui me gène dans le résultat de ton
Ton fichier est exécuté 2 fois (
La 2nd fois c'est le shell bash qui l'exécute (comme dans le shebang (
La 1ère fois c'est le shell sh qui l'exécute, faisant fi du shebang et comme
À vérifier…
Moi ce qui me gène dans le résultat de ton
ps aux | grep "ufw"c'est
/bin/sh -c /root/ufw_conf.sh;-\
Ton fichier est exécuté 2 fois (
/bin/bash /root/ufw_conf.sh) ;-\
La 2nd fois c'est le shell bash qui l'exécute (comme dans le shebang (
#! /bin/bash) de ton script).
La 1ère fois c'est le shell sh qui l'exécute, faisant fi du shebang et comme
/bin/shest un lien symbolique vers
/bin/dash, peut-être y-a-t-il des erreurs de syntaxe ;-(
À vérifier…
hello
pour récupérer les messages et erreurs du cron, ajouter à la ligne dans crontab
avec les droits root (permission spéciale u+s) le script démarre mais ne fonctionne pas.
beaucoup de systèmes empêchent les scripts suid root pour des questions de sécurité, essayer
pour récupérer les messages et erreurs du cron, ajouter à la ligne dans crontab
.... > /tmp/log 2>&1
avec les droits root (permission spéciale u+s) le script démarre mais ne fonctionne pas.
beaucoup de systèmes empêchent les scripts suid root pour des questions de sécurité, essayer
sudo ufw_conf.sh
salut,
je vais le dire crûment, sans vouloir te blesser, ton script est merdique.
pourquoi la variable COUNTER (qui devrait être écrite en minuscule : par convention seules les variables d'environnement doivent être tout en majuscules) n'est-elle en aucun cas incrémentée ?
pourquoi utiliser
pourquoi
pourquoi
je vais le dire crûment, sans vouloir te blesser, ton script est merdique.
pourquoi la variable COUNTER (qui devrait être écrite en minuscule : par convention seules les variables d'environnement doivent être tout en majuscules) n'est-elle en aucun cas incrémentée ?
pourquoi utiliser
cat, alors que
grepsait lire des fichiers ?
pourquoi
readlit-il un fichier (
$1) qui n'est pas donné en argument au script ?
pourquoi
truncateplutôt que
rm, ou un simple écrasement par redirection ?
Slt je suis d'accord avec toi, il y a des points à améliorer :
pourquoi la variable COUNTER n'est-elle en aucun cas incrémentée ?
==>> j'ai besoin d'une boucle permanente et d'après mes rapides recherches il n'y a pas GOTO en bash donc je me suis rabattu sur la boucle WHILE, avec une variable fixe
pourquoi utiliser cat, alors que grep sait lire des fichiers ?
==>> comme expliqué dans le titre, j'avais quelques problèmes avec l'exécution du script et je n'ai pas voulu foutre encore plus le bordel en modifiant ce qui marchait bien, j'ai préféré garder la commande qui fonctionnait le mieux à ce moment là
pourquoi read lit-il un fichier ($1) qui n'est pas donné en argument au script ?
==>> erreur de retranscription de ma part, ce n'est pas $1 mais bien la variable $fichier
pourquoi truncate plutôt que rm ou un simple écrasement par redirection ?
==>> je ne souhaite pas supprimer le fichier sinon il faut le recréer avec les bonnes permissions, un simple écrasement par redirection me convient très bien, je sais faire en MS-DOS mais pas en bash :(
Maintenant que j'ai réglé les problèmes d'exécution, je peux me focaliser sur l'optimisation du script, je veux bien ton aide pour améliorer certains points.
pourquoi la variable COUNTER n'est-elle en aucun cas incrémentée ?
==>> j'ai besoin d'une boucle permanente et d'après mes rapides recherches il n'y a pas GOTO en bash donc je me suis rabattu sur la boucle WHILE, avec une variable fixe
pourquoi utiliser cat, alors que grep sait lire des fichiers ?
==>> comme expliqué dans le titre, j'avais quelques problèmes avec l'exécution du script et je n'ai pas voulu foutre encore plus le bordel en modifiant ce qui marchait bien, j'ai préféré garder la commande qui fonctionnait le mieux à ce moment là
pourquoi read lit-il un fichier ($1) qui n'est pas donné en argument au script ?
==>> erreur de retranscription de ma part, ce n'est pas $1 mais bien la variable $fichier
pourquoi truncate plutôt que rm ou un simple écrasement par redirection ?
==>> je ne souhaite pas supprimer le fichier sinon il faut le recréer avec les bonnes permissions, un simple écrasement par redirection me convient très bien, je sais faire en MS-DOS mais pas en bash :(
Maintenant que j'ai réglé les problèmes d'exécution, je peux me focaliser sur l'optimisation du script, je veux bien ton aide pour améliorer certains points.
1- une boucle infinie s'écrit
n'existe-t-il vraiment pas une condition qui doit faire quitter le script.
pourquoi n'est-il pas plutôt inscrit dans une crontab ? sans boucle infinie, donc.
même un petit script qui s'exécute en permanence finit par consommer beaucoup de ressources.
2- c'est un UUOC.
3- ok
4-
while true; do...; done
n'existe-t-il vraiment pas une condition qui doit faire quitter le script.
pourquoi n'est-il pas plutôt inscrit dans une crontab ? sans boucle infinie, donc.
même un petit script qui s'exécute en permanence finit par consommer beaucoup de ressources.
2- c'est un UUOC.
3- ok
4-
>fichier_à_écraser, c'est aussi simple que ça.
Voilà la version actuelle :
Si tu vois d'autres choses, fais-moi signe.
#! /bin/sh fichier=/var/www/parefeu/ip_address.txt # on crée une boucle infinie while true; do # on ralentit la boucle /bin/sleep 1 # on vérifie si le fichier est vide ou pas # /usr/bin/test -s $fichier || continue /bin/grep ":" || continue # on lit les infos dans le fichier texte IFS=':' read -r adresse port <$fichier # on crée une nouvelle règle /usr/sbin/ufw allow in proto tcp from $adresse to any port $port # on réinitialise le fichier texte >$fichier # on recharge le pare-feu /usr/sbin/ufw reload done
Si tu vois d'autres choses, fais-moi signe.