human panic ! chown -R root:root / [Réglé]
bêtes manipulations en root - tentative de récupération
Système et matériels / Installation et configuration
Tonin Membre non connecté
-
- Voir le profil du membre Tonin
- Inscrit le : 02/07/2013
- Groupes :
suite à une malheureuse bourde, me voilà dans une situation délicate... renverser la vapeur ou réinstaller mon système.
La bourde tient en quelques lignes, par cet extrait de l'historique des commandes passées en root :
Ces commandes ont été exécutées depuis un répertoire du genre /home/myusername/webimages/a/b/c/
Code TEXT :
# history 52 chown -R myusername:wwwdata *.jpg 53 chown -R myusername:wwwdata /*/*/ 54 chown -R myusername:wwwdata ./ 55 chown -R root:root /
À ce moment là, la prise de conscience commence à faire mal, et la situation se redressera un peu par des commandes pour rétablir les droits myusername dans son dossier
Code TEXT :
56 chown -R myusername:myusername /home/myusername/ 57 chown -R myusername:wwwdata /home/myusername/yaya/ ...
Tout n'est pas perdu, mais déjà les dysfonctionnements pointent leurs nez, et les marges de manœuvre s’amenuisent : boinc s'arrête ; kate/dolphin ne peut plus parcourir l'arborescence (erreur io-slave) ; depuis une console myusername impossible de passer en root, le mot de passe root n'est plus reconnu ; thunderbird n'arrive plus à collecter les messages dans /var/mail/myusername ; ...
L'espoir tient à une fenêtre mcc restée ouverte, car elle permet d'accéder à une console root. J'ai désactivé le verrouillage de la session graphique, ce n'est pas un temps à rester enfermé dehors.
En pareille situation, l'internet suggère notamment de rétablir des droits utilisateurs à partir des paquets rpm
Code TEXT :
rpm --setperms -a rpm --setugids -a
Ça s'exécute jusqu'à son terme, en laissant voir un grand nombre d'alertes pour fichiers inaccessibles, mais ce sont essentiellement des fichiers de langues exotiques.
Avant de tenter un redémarrage, je voudrais m'assurer de pouvoir relancer une console root, et que le système soit en mesure de se relancer à peu près d'applomb...
"$ => #" : true
Ha ! les deux commandes précédentes ont pu produire leur effet, la commande et le mot de passe root sont à nouveau possibles depuis la konsole.
De suite, ça va beaucoup mieux !
Il faudra que je jette un œil sur une installation similaire (Mageia 5) pour voir quels utilisateurs et quels groupes ont perdu leurs privilèges...
À coup de
find / -user toto
et find / -group lulu
; dessiner une telle carte des fichiers/utilisateurs/groupes parait bien difficile et peu pragmatique. D'autant que ça n'apportera peut-être rien de plus que la paire de commande rpm.Si quelqu'un d'autre que Morphée à des conseils à me prodiguer, c'est avec intérêt que je les considérerai.
Édité par Tonin Le 02/08/2017 à 01h43
magnux77 Membre non connecté
-
- Voir le profil du membre magnux77
- Inscrit le : 21/09/2009
- Groupes :
-
Membre d'Honneur
chown -R
Il m'est arrivé la même blague, peut-être plus limitée, sur le serveur pour la quelque centaine de développeurs, vers 20H quand il n'y a plus un admin système pour t'aider. Alors, même en salle trop climatisée, tu sens la transpiration perler dans ton cou...
Erreur typique de quand on commence à maîtriser et que la fatigue ou l'agacement émoussent un peu la vigilance.
Citation :
Avec un système de fichier root:root, il ne doit pas être impossible de lancer une console root. Avant de tenter un redémarrage, je voudrais m'assurer de pouvoir relancer une console root
Pour les conseils, pas mieux que Morphée. As-tu redémarré depuis ?
Tonin Membre non connecté
-
- Voir le profil du membre Tonin
- Inscrit le : 02/07/2013
- Groupes :
Code TEXT :
rpm --setugids -a chown myusername. /var/spool/mail/myusername rpm --setugids -a (y a-t-il un intérêt à plusieurs passes ?) rpm --setperms -a find / -group adm find / -user adm chgrp adm /var/log/msec* chgrp adm /var/log/security* chgrp mysql /var/log/mysqld/* chgrp systemd-journal /var/log/journal/* chgrp utmp /var/log/btmp* chown -R mysql. /var/lib/mysql/*
Et, le redémarrage s'est effectué avec succès. Le son qui avait lui aussi disparu est revenu, Dolphin s'y retrouve à nouveau, ...
L'appliquette de mise à jour râle parce qu'elle ne s'y retrouve plus, donc :
Code TEXT :
chown -R myusername. /tmp/.urpmi-1012/
Ça marche assez bien, mais je n'ai pas reçu mon récap cron msec de cette nuit... donc, évidemment, il reste encore du sable dans les rouages (voire beaucoup de sable et du gravier)
Tonin Membre non connecté
-
- Voir le profil du membre Tonin
- Inscrit le : 02/07/2013
- Groupes :
En supposant que les uid et gid n'ont pas changés entre les deux installations (*), elle est utilisée pour comparer les privilèges des users et groups sur les deux systèmes.
D'un coté, en exécutant sur un terminal ouvert en /mnt/sda9 (code TEXT)
Code TEXT :
find . -user polkitd find . -user systemd-resolve find . -group bin
De l'autre coté, sur un autre terminal à la racine / du système (code BASH)
(recherches similaires en excluant le dossier /mnt/sda9)
Code BASH :
find / -path /mnt/sda9 -prune -o -user polkitd find / -path /mnt/sda9 -prune -o -user systemd-resolve find / -path /mnt/sda9 -prune -o -group bin
Quand il y a des différences, le système courant est mis à jour.
Code BASH :
chown polkitd /etc/polkit-1/rules.d chown systemd-resolve /var/lib/systemd/journal-upload chown systemd-network /var/lib/systemd/journal-upload chgrp bin /usr/sbin/traceroute
(*) Mais, il faut rester critique, car manifestement les uid et gid peuvent être différents entre les deux installations. Les différences suivantes n'ont pas été propagées :
Code TEXT :
find . -group systemd-network ./var/lib/systemd/journal-upload find . -group systemd-timesync ./usr/libexec/kf5/kdesud find . -group vcsa ./var/lib/mlocate ./var/lib/mlocate/mlocate.db ./usr/bin/locate find . -group ntools ./var/state/ups ./etc/ups/upsmon.conf ./etc/ups/upssched.conf find . -group apache ./var/log/mysqld ./var/lib/mysql ./var/lib/mysql/test ./var/lib/mysql/mysql
Autre limite de cette solution de comparaison, c'est que le premier système installé était plus simple que le courant.
À présent, après ce redémarrage, j'espère que sectool enverra à nouveau ses rapports, dès fois qu'il soit en mesure de lister les modifications apportées au système depuis son dernier message du 1er août...
Tonin Membre non connecté
-
- Voir le profil du membre Tonin
- Inscrit le : 02/07/2013
- Groupes :
il a fallu réanimer x2goserver, postfix, shorewall (désinstallation-réinstallation) + redéfinition des zones à la main (grâce aux fichiers /etc/shorewall/*.rpmsave) :
Code TEXT :
chgrp -R x2gouser /var/lib/x2go/ x2godbadmin --createdb chown -R postfix /var/spool/postfix chown -R postfix /var/lib/postfix vim /etc/shorewall/zones
Nul doute qu'il reste encore des "grains de sable" ci et là, mais maintenant j'ai l'impression d'avoir recouvré tout les usages que ma bourde a pu chambouler.
Mercis à Morphée, magnux77, au petit remontant ainsi qu'au taureau qui a bien voulu se laisser prendre par les cornes !
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie