Chmod -R 444 / => Aie aie aie

[quote=“fran.b”]À vue de nez /var/lib/php5, il a des droits curieux: 1733…

drwx-wx-wt 2 root root 4096 févr. 13 12:09 php5
[/quote]
Mêmes droits chez moi :017 mais ce dossier est vide et je ne sais pas comment il a atterri ici.
Que veux dire ce ‘t’ :question:

Je me réponds :

[code]1. Le Sticky bit
Le Sticky bit est un droit spécial dont le comportement est différent pour les fichiers exécutables et les répertoires.
Il correspond à la lettre t ou numériquement à 1000.
Si les droits d’exécution ne sont pas positionnés c’est la lettre T qui correspond.

les fichiers exécutables - le programme restera en mémoire pour une exécution ultérieure
les répertoires - si le sticky bit est positionné sur un répertoire, seul le propriétaire pourra supprimer ses fichiers (c'est le cas des répertoires /tmp et /var/tmp sous GNU/Linux)

Exemple :

$ ls -l / | grep tmp;ls -l /var | grep tmp
drwxrwxrwt 12 root root 1024 2006-07-22 14:18 tmp
drwxrwxrwt 4 root root 4096 2006-07-22 10:23 tmp

C’est l’affichage des droits pour /tmp et /var/tmp.
Nous remarquons que le dernier caractère dans la suite des 9 pour les droits est un t et pas un x ou un tiret. [/code]

Ce script récupère la liste des fichiers installés sur le système, que l’on trouve dans le répertoire /var/lib/dpkg/info/*.list. A la différence de la commande ‘find . -prinf’ de fran.b, ce script récupère les informations contenues dans les paquets, et non celles du système (Qui serait sans intérêt puisque les permissions du système sont cassées). Ensuite, pour chaque paquet trouvé dans cette liste, il va :

Télécharger le paquet depuis le dépôt dans un répertoire temporaire et le décompresser.
Puis, pour chaque fichier/répertoire du paquet décompressé dans ce répertoire temporaire, récupérer les informations d’utilisateur, groupe et mode, et ajouter dans un script ‘RestorePerms.sh’ les opérations chown et chmod permettant de remettre les bons utilisateurs, groupes et droits sur les fichiers réellement installés.

Petite précision à ce sujet, le script ‘RestorePerms.sh’ créé par ce petit programme est à lancer à la racine (/) du système en tant que root.

PS : Par contre, vu la commande que te donne fran.b sur son site, il est possible (et diablement plus efficace) de remplacer toute la partie

[code] for FILE in find .; do
USR=stat --printf="%U" $FILE
GRP=stat --printf="%G" $FILE
MOD=stat --printf="%a" $FILE

# On cree les commandes dans le script de sortie
echo "chown $USR:$GRP $FILE" >> $SCRP
echo "chmod $MOD $FILE" >> $SCRP

done[/code]

par la simple ligne

Voila. Si tu as d’autres question, n’hésites pas.

Salut !

D’accord, merci beaucoup pour l’explication ! Je lancerai ce code dès que possible, mais actuellement j’en ai pas la possibilité

En revanche, je dois d’abord régler très rapidement ce problème de droit pour PHP5 :

C’est vraiment très problématique car le site est hors service du coup :-/

Tu as mis les permissions 1733 comme je t’ai suggéré?

Non j’avais fait 733, ça ne fonctionne donc pas.

visiblement c’est beaucoup mieux !

Y’a plus l’air d’avoir de problèmes…

Je vais jouer le script de NooP quand je le pourrai, et je tâcherai de garder ça en sûreté, au cas où…

Je vous remercie vraiment pour l’aide rapide et efficace que vous m’avez donnée.

Résolu :question:

[quote=“jodu”]
Je vais jouer le script de NooP quand je le pourrai, et je tâcherai de garder ça en sûreté, au cas où…

Je vous remercie vraiment pour l’aide rapide et efficace que vous m’avez donnée.[/quote]

Le script de Noop est une réparation des droits standards, là où ça a coincé, ce sont les droits spécifiques. Si tu veux sauvragder les droits de tes fichiers et répertoire, utilise plutôt la commande

par exemple ou le script dont je t’avais donné le lien (qui fait la même chose).

Je suis entièrement d’accord avec toi. Seulement, si j’ai proposé ce script, c’est bien parce Jodu à donné les droits 444 au système tout entier. Il doit alors y avoir des ‘coins’ où les permissions ne seront plus les bonnes. Et ça, c’est très vicieux, parce que tout fonctionne correctement et quelques mois plus tard, on modifie un truc, plus rien ne fonctionne comme il devrait, et on ne fait plus forcément le lien avec cette mauvaise manipulation faite plus tôt.

PS : Pour que ce script fonctionne, il lui faut un accès aux dépôts, puisqu’il doit re-télécharger l’intégralité des paquets installés. Ensuite, j’ai bien spécifié qu’il était à utiliser en ultime recours. Dans tous les cas, ne pas le lancer sans avoir une sauvegarde intégrale du système.

Hello !

Oua, heureusement que je n’ai pas exécuté le script alors ! En tous cas tout est quasiment opérationnel mais je rencontre quelques erreurs sur certaines requêtes de l’Intranet :

[quote]Warning: mysql_connect(): Acc�s refus� pour l’utilisateur: ‘www-data’@’@localhost’ (mot de passe: NON) in /var/www/unchemin/unfichier.php on line 15
uneFonction : message d’erreur [/quote]

Vous auriez une idée ?

C’est bizarre, c’est en général

‘www-data’@‘localhost’ (pas 2 «@»!)

et c’est étonnant qu’il n’y ait pas de mot de passe (droit réduit à la lecture?).

Vérifie que tu peux accéder à la base de données en local:

mysql -u root -p «mot de passe root» use basededonnées; show tables; select * from une_des_tables;
par exemple.

Si c’est le cas ajuste les droits de www-data, sinon vérifies les droits dans /var/lib/mysql (mais on les avait bien refait je crois)

Salut,

La base de données en root marche sans aucun problème. Les droits de www-data doivent être mauvais mais comment corriger ?

Normalement oui la manip dans /var/lib/mysql avait été faite :

Il faudrait savoir ce que fait www-data sur la base. À la louche ce serait

grant Select ON `intranet`.* TO 'www-data'@'localhost'; FLUSH PRIVILEGES;
(ça donne un accès en lecture à la base de données intranet.
Sinon, tu peux faire

grant all ON `intranet`.* TO 'www-data'@'localhost'; FLUSH PRIVILEGES;
Là ça donne tous les droits sur cette base mais c’est ennuyeux.

Le problème viendrait pas plutôt des répertoires dans /var/www/leChemin ?

Je ne crois pas, vérifies qd même, les fichiers dans ces répertoires doivent avoir les droits 660 et appartenir à mysql, mais je n’y crois pas. Cette erreur n’existait pas avant?

L’erreur est là depuis ma commande foireuse. Avant ça tournait, c’est certain.

Actuellement tous mes fichiers sont en :

[quote]-rwxrwxr-x 1 root root 5970 4 oct. 13:29 blabla.php
[/quote]

Mais y’a que la partie chmod qui a été changée… donc je vois pas ce qui cloche là en effet

Quelle est la requête que fait www-data sur la base de donnée?, C’est bizarre car a priori les droits sont gérés par mySQL et n’ont pas de rapport avec les droits de fichiers…

En fait ce n’est pas une requête, mais une connexion avec mysql_connect($config['mysql_host'], $config['mysql_username'], $config['mysql_password'])
avec :

Le problème viendrait alors de cet user ? Mais pourquoi impacté par le chmod ?

Le message d’erreur est

[quote]Warning: mysql_connect(): Acc�s refus� pour l’utilisateur: ‘www-data’@’@localhost’ (mot de passe: NON) in /var/www/unchemin/unfichier.php on line 15[/quote]donc l’utilisateur www-data sans mot de passe essaye de se connecter directement à une base de données. Le fichier concerné est /var/www/unchemin/unfichier.php, est ce un fichier qui vient de chez toi ou bien est ce un fichier extérieur essayant de rentrer dans tes bases de données? Regarde mieux ce fichier et ce qu’il y a à la ligne 15

Oui oui, la ligne que je t’ai mise est bien la ligne incriminée par le message d’erreur.