Problème droits root et divers
Résolu
barnabe0057
Messages postés
14455
Date d'inscription
Statut
Contributeur
Dernière intervention
-
barnabe0057 Messages postés 14455 Date d'inscription Statut Contributeur Dernière intervention -
barnabe0057 Messages postés 14455 Date d'inscription Statut Contributeur Dernière intervention -
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
- Vous devez disposer des droits d'administrateur pour supprimer ce dossier - Guide
- Les textes ne doivent pas être en retrait à droite et à gauche - Guide
- Donnez à ce fichier les mêmes droits d'accès que les autres notes de service. ✓ - Forum Windows
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
14455
Date d'inscription
Statut
Contributeur
Dernière intervention
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
2126
Date d'inscription
Statut
Contributeur
Dernière intervention
496
Il peut avoir les droits d'exécution mais pas d'écriture ^^
barnabe0057
Messages postés
14455
Date d'inscription
Statut
Contributeur
Dernière intervention
4 925
Ok j'ai rajouté root au groupe www-data, je vais tester.
barnabe0057
Messages postés
14455
Date d'inscription
Statut
Contributeur
Dernière intervention
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.