Chmod -R 444 / => Aie aie aie

Support Debian
#1

Bonjour à tous.

Pour une fois que je me connecte en root pour une histoire de gestion de droits à changer dans un dossier, j’ai fait une boulette monstrueuse :

chmod -R 444 /

:078

Eh oui, il manquait un tout petit “.” avant le “/” et j’ai complètement massacré mon serveur… Ne pouvant plus rien faire, j’ai tenté une manoeuvre de récupération à l’aide d’un live CD. Pour ce faire j’ai lancé un :

chmod -R 774 /media/sys sur le disque système que j’ai préalablement monté.

Or, maintenant, je ne peux plus rien faire. C’est à dire:
[ul][li] Impossible de se connecter via SSH en root.[/li]
[li] Impossible de lancer un terminal administrateur [/li]
[li] Impossible de lancer la commande su / sudo[/li][/ul]

Ce qui est problématique.

Alors bien sûr j’avais prévu de réinstaller l’intégralité de Debian et repartir sur de bonnes bases, MAIS, je n’arrive pas a monter mon disque dur externe afin de sauvegarder toutes mes petites configs personnelles (genre openvpn, samba, mysql, etc etc…) et j’ai pas envie de tout me retaper (surtout pas la base de données que je ne peux pas sauvegarder).

Auriez-vous une solution autre que le liveCD pour me débloquer de cette galère ? Je pense que c’est pas possible de lancer un programme comme MySQL si je monte le disque système via un liveCD…

Merci par avance.

:shameonme:

#2

Salut,

Si un live CD te permettrait de faire un chroot, et peut-être (en réparant un peu les droits) de lancer tes programmes (dont mysql).

#3

Malheureux …

Comment ça ?

  • Situation …

Tu as rebooter à partir d’un live-cd, ensuite que fais tu ?

tu chroot ?

  • quels sont les commandes lancés ?

  • Tant qu’on y est … (avec le dd externe monté)

#4

Tu as un script ici boisson.homeip.net/debian/sauveg … ze_i386.gz qui devrait te remettre des droits fondamentaux pour la plupart des fichiers. Après, il te faudra adapter (pense à /var/lib/mysql par exemple).

Tu télécharges le script, tu l’exécutes apèrs l’avoir décompressé.

Tu as également boisson.homeip.net/debian/droits_wheezy_amd64.gz mais c’est un exemplaire de ma machine actuelle et non d’une machine standard.

#5

Bonjour bonjour !

Alors en fait je me suis mal exprimé, j’ai réparé mes droits à l’arrache avec le fameux chmod 774, et vu que ce serveur est en prod (en local dans mon entreprise) j’ai pas le loisir de le rendre indisponible sans prévenir, du coup j’ai pas remis de liveCD.

Ce que je ne comprends pas, c’est pourquoi ça ne fonctionne plus (le root) malgré les droits que j’ai mis ?

[quote=“fran.b”]Tu as un script ici boisson.homeip.net/debian/sauveg … ze_i386.gz qui devrait te remettre des droits fondamentaux pour la plupart des fichiers. Après, il te faudra adapter (pense à /var/lib/mysql par exemple).

Tu télécharges le script, tu l’exécutes apèrs l’avoir décompressé.

Tu as également boisson.homeip.net/debian/droits_wheezy_amd64.gz mais c’est un exemplaire de ma machine actuelle et non d’une machine standard.[/quote]

Si je comprends bien, d’après ce que tu me dis, il n’y aurait même pas besoin de réinstaller le système avec les fameuses commandes remettant les droits ?

#6

parceque ils n’ ont plus le setuid, voir debian-fr.org/su-impossible- … 42372.html

#7

Ce sont les suid qui mettent la pagaille, en plus ce serait plutôt 775 sinon les répertoires ne sont pas accessibles pour les non propriétaires.
Fais ton chmod 775, puis exécute les scripts.
Ça n’est pas forcément nécessaire de réinstaller mais il faut être attentif à la machine et regarder les répertoires particuliers.

#8

Merci de votre aide !

Alors je vais booter sur le liveCD, et effectuer ces commandes :
[ul]
[li]chmod -R 775 /[/li]
[li]chown root /bin/su[/li]
[li]chmod u+s /bin/su[/li][/ul]

Je redémarre le bouzin en mode normal et j’exécute ton script. Ca devrait le faire ?

#9

Oui, ne t’inquiètes pas des erreurs de fichiers non trouvés, c’est normal.

#10

Ok alors autre problème, j’ai bien effectué les commandes en mode liveCD.

Je restart le serveur et ô surprise, impossible de l’ouvrir. C’est une Debian en mode graphique donc qui plante grave au démarrage.

Et à partir d’ici, je ne peux même pas ouvrir de terminal tant le bureau s’ouvre merdiquement. Merci au mode graphique quoi.

Et du coup j’ai eu un gros WARNING au démarrage concernant les RSA files chose du genre. Mon putty ne fonctionne toujours pas à distance pour ouvrir un terminal SSH…

EDIT : ok en fait pour le graphique j’ai simplement oublié de remettre les droits correctement sur /tmp.

EDIT 2 : en revanche, toujours pas de possibilité d’exécuter des commandes en root malgré les manips faites : [quote]Impossible de lancer /usr/bin/x-terminal-emulator en tant qu’utilisateur root.

Echec de la communication avec gksu-run-helper.

Reçu :
setgid : opération non permise
Ce qui était attendu :
gksu : waiting[/quote]

#11

Normal, je n’utilise pas gksu, cela explique tes soucis, pour le répertoire tmp c’est curieux mais bon.

Rénstalle le paquet gksu ou met un suid sur gksu.

#12

Je suis désolé mais tu vas un peu trop loin pour moi là…

Je n’ai aucun droit root, je ne peux rien faire en mode normal. Quelles commandes dois-je entrer en mode live CD ? Car j’imagine que l’installation se passe différemment dans ce cas…

#13

Si, tu as les droits root, il te suffit d’ouvrir une console normale (voire de taper Ctrl-Alt-F1 et d’avoir une console texte), et là tu tapes

Le mot de passe de root
et tu fais le changement chmod +s /usr/bin/gksu* (ou encore tu réinstalles le paquet gksu:

Si tu as choisi de faire Ctrl-Alt-F1, là tu entres le login/mot de passe de root.

Enfin, dans le cas où root n’a pas de mot de passe, là il te suffit de taper

Dans un console et ton mot de passe.

#14

[quote=“fran.b”]Si, tu as les droits root, il te suffit d’ouvrir une console normale (voire de taper Ctrl-Alt-F1 et d’avoir une console texte), et là tu tapes

Le mot de passe de root[/quote]

Rigolo, y’a que le terminal Ctrl+Alt+F1 qui marche. Le reste que d’hal. Accès SSH fonctionne pas également.

[quote=“fran.b”]et tu fais le changement chmod +s /usr/bin/gksu* (ou encore tu réinstalles le paquet gksu:

Ok, fait. J’ai réinstallé. Rien de neuf en termes de droit, je peux toujours pas ouvrir de terminaux en mode graphique, même erreur.

Néanmoins, j’ai pu exécuter ton script. Et visiblement c’est censé aller mieux pour les droits mais y’a encore des erreurs…

EDIT : Ok, j’ai reboot le serveur, aucun problème de droit pour le root ça a l’air de fonctionner cette fois.

Où penses-tu qu’il y ait des grosses failles désormais ? Hormis dans /var/www par exemple…

En revanche, toujours impossible de se connecter en SSH dessus :confused:

Edit 2 : j’ai une 50aine de MàJ à faire, dois-je les faire vu la situation peu stable de la bécane ?

#15

Vérifies les droits de /var/run et des répertoires de /home (qui ne sont pas précus dans mon script), ça devrait arranger les choses. Les mises à jour ne peuvent qu’améliorer les choses en terme de droits et mettent à l’épreuve la machine. Personnellement je continuerais.

#16

Salut,

pour /home normalement c’est ok, c’est du 0775 de partout.

Pour /var/run/ je ne sais pas quels sont les bons droits…

Au démarrage j’ai ces erreurs qui m’inquiètent (voir photo…)

https://lh3.googleusercontent.com/-OlgqiJwsRME/UTccoC3J7BI/AAAAAAAADOE/JVnGY7TJScc/s631/IMG_20130306_113057.jpg

Donc clairement y’a un souci de droits. Faut-il réinstaller le module complet ?

Ton script m’a déjà bien dépatouillé… Merci beaucoup.

#17

Non pas de souci,
.ssh doit avoir comme droit 700 et toutes les clefs privées sous .ssh (sans suffixe.pb) également.

Pour /etc/ssh, les clefs privées sous ce répertoire également.

Pour /etc/ssl:

[code]-rw-r–r-- 1 root root 10835 mars 13 2012 openssl.cnf
drwxr-xr-x 4 root root 4096 mars 22 2012 .
drwx–x— 2 root ssl-cert 4096 mars 22 2012 private
drwxr-xr-x 3 root root 20480 mars 22 2012 certs
drwxr-xr-x 151 root root 12288 mars 6 12:27 …

ls -l /etc/ssl/private/

total 4
-rw-r----- 1 root ssl-cert 1704 mars 22 2012 ssl-cert-snakeoil.key
[/code]pense également aux clefs simples de /etc/openvpn si tu as des vpns)

#18

Je vois également que mysqld ne démarre pas, /var/lib/mysql appatient à mysql, a les droits 700 et surtout dedans, les droits sont les suivants:

-rw-r--r-- 1 mysql mysql 0 mai 13 2012 debian-5.1.flag -rw-rw---- 1 mysql mysql 5242880 mai 13 2012 ib_logfile1 -rw-r--r-- 1 root root 0 sept. 20 07:47 debian-5.5.flag drwx------ 2 mysql root 4096 sept. 20 07:47 BASE_QUELCONQUE drwx------ 2 mysql mysql 4096 sept. 20 07:47 performance_schema drwx------ 4 mysql mysql 4096 sept. 20 07:47 mysql -rw------- 1 mysql mysql 6 sept. 20 07:47 mysql_upgrade_info drwxr-xr-x 65 root root 4096 nov. 23 09:07 .. -rw-rw---- 1 mysql mysql 18874368 mars 6 12:18 ibdata1 drwx------ 10 mysql mysql 4096 mars 6 12:27 . -rw-rw---- 1 mysql mysql 5242880 mars 6 12:27 ib_logfile0
et tous les fichiers dans /var/lib/mysql/BASE_QUELCONQUE ont comme droits 660. (Un chmod 660 /var/lib/mysql// devrait suffire pour ce dernier point)

#19

Ah merci bien, je vais faire la MàJ dès que j’aurai accès au serveur.

Merci beaucoup pour les captures d’écran des droits.

J’ai effectivement un VPN monté, j’applique les droits 700 sur toutes les clés c’est ça ?

Je pourrai te passer une capture d’écran pour que tu vérifies, si tu le veux bien…

#20

Ok, oui, voilà un exemple de répertoire openvpn

-rw-r--r-- 1 root root 1224 sept. 18 2008 ca.crt -rw------- 1 root root 887 sept. 18 2008 ca.key -rw------- 1 root root 636 f�vr. 11 2010 clefserveur.key -rw-r--r-- 1 root root 245 sept. 18 2008 dh1024.pem -rw------- 1 root root 0 mars 6 14:49 ipp.txt -rw------- 1 root root 232 mars 6 14:49 openvpn-status.log -rw-r--r-- 1 root root 318 f�vr. 1 2010 server.conf -rw-r--r-- 1 root root 302 oct. 19 2008 server.conf~ -rw-r--r-- 1 root root 3647 sept. 18 2008 serveur.crt -rw------- 1 root root 887 sept. 18 2008 serveur.key -rw-r--r-- 1 root root 145 f�vr. 11 2010 #test.conf# -rw-r--r-- 1 root root 145 f�vr. 11 2010 test.conf -rw-r--r-- 1 root root 144 f�vr. 11 2010 test.conf~ -rw-r--r-- 1 root root 349 d�c. 24 2010 tun.conf -rw-r--r-- 1 root root 318 d�c. 24 2010 tun.conf~ -rwxr-xr-x 1 root root 1352 sept. 18 2008 update-resolv-conf

Pense également aux répertoires où tu fabriques les clefs (il faut le protéger) et au répertoire de root