Récupération après avoir défini le shell de root sur un fichier incorrect


23

Disons que je suis allé faire une chose idiote, comme utiliser 'chsh' pour changer le shell de l'utilisateur root en un mauvais chemin de fichier. Les futures connexions au compte root échoueront brusquement, citant / bin / tout ce qui n'est pas trouvé, et vous redémarreront à l'écran de connexion. À moins d'un mode de récupération ou d'insertion d'un LiveCD pour éditer / etc / passwd, quelles sont mes options pour récupérer mon système? Supposons également (pour le plaisir?) Qu'il n'y ait pas d'autres utilisateurs dans la roue. Pensées?


Est-ce une situation hypothétique que vous proposez?
Chris Down

J'avais en effet fait exactement cela sur une installation (relativement récente) de FreeBSD. Il a depuis été réinstallé, donc je suppose qu'il est maintenant quelque peu hypothétique, mais je suis curieux de savoir quelle aurait été la meilleure voie de récupération si j'avais effectivement le système complet présent.
noffle le

J'y suis allé, j'ai fait le t-shirt. Mais par conséquent, sur chaque machine que j'administre, je conserve un compte racine de sauvegarde, au cas où.
Mark D

Réponses:


30

Lors du démarrage, ajoutez init=/bin/bash(ou un chemin vers tout autre shell fonctionnel) à vos options de démarrage - vous serez déposé directement dans un shell utilisateur unique. Vous devrez peut-être le faire mount -o remount,rw /avant de modifier l' /etc/passwdentrée dans cet environnement. Après cela, redémarrez ou faites exec /sbin/init 3. Il suffit de ne pas taper exitou d'appuyer sur Ctrl + D, car cela entraînerait une panique du noyau *.

Une variante supplémentaire de cette méthode peut être nécessaire sur certains systèmes chargés en mode en deux étapes (avec une image initrd). Si vous remarquez que les options de démarrage contiennent init=et, plus important encore, real_init=alors la place à mettre /bin/bashdevrait être le dernier paramètre (ie real_init=/bin/bash).

* C'est parce que dans cet environnement, le shell est vu par le noyau comme le programme init - qui est le seul processus que le noyau connaisse - il représente un système en cours d'exécution sous les yeux du noyau. La fin soudaine de ce processus, sans demander au noyau d'arrêter le système, doit entraîner une panique du noyau. (Ne paniqueriez-vous pas si tout à coup tout autour de vous devenait noir et silencieux?)


Bien pour le exec, mais je suppose qu'il vaut mieux ne pas trop gâcher les points de montage au préalable.
Stéphane Gimenez

2
@ Stéph Vous devez le faire si votre noyau ne monte pas en lecture-écriture root. Sinon, vous ne pourrez modifier aucun fichier (y compris /etc/passwd).
rozcietrzewiacz

Bien pensé! J'avais réussi à passer en mode mono-utilisateur, mais cela ne m'a pas frappé de devoir remonter / en lecture / écriture pour modifier / etc / passwd. Merci!
noffle

@roz Bien sûr, j'essayais de dire que je m'occuperais de démonter tout ce qui aurait pu être monté (autre que /) avant d'exécuter init.
Stéphane Gimenez

@ Stéph Il ne devrait pas y avoir de problèmes avec les supports. Notez qu'il /bin/bashest exécuté exactement au point, puis /sbin/initserait exécuté au démarrage normal. Il ne peut donc y avoir aucune action possible du système à ce moment-là.
rozcietrzewiacz

10

Vous pouvez utiliser suet spécifier un shell à exécuter (je ne suis pas sûr si vous essayez d'impliquer que ce n'est pas possible avec votre note qu'aucun autre utilisateur ne s'y trouve wheel):

su -c /bin/bash

Sinon, vous pourriez faire quelque chose de similaire si votre démon ssh autorise la connexion à root:

ssh root@localhost /bin/bash

Vous pouvez également définir un shell comme init dans votre chargeur de démarrage, par exemple, init=/bin/kshou similaire.


1
Bonnes idées. =) Comme vous le soupçonniez, aucun autre utilisateur ne peut utiliser 'su'. sshd a également la connexion root désactivée.
noffle

6

Si votre chargeur de démarrage est configuré pour permettre l'édition en direct des paramètres du noyau, une solution consiste à redémarrer et à utiliser un shell comme processus d'initialisation, par exemple init=/bin/bash. Ensuite, montez tout ce qui doit être monté à la main et éditez /etc/passwd. syncet redémarrez avec votre habitude init.


Wow, je viens de remarquer que vous avez posté la même réponse dans la même minute que moi :-)
rozcietrzewiacz

6

Si l'essentiel de votre question est que vous avez verrouillé toutes les façons de devenir root, alors par définition, vous ne pouvez pas devenir root.

Il est courant d'autoriser trois méthodes pour devenir root sur un système Unix:

  • Connectez-vous en tant que root, en entrant rootà l'invite de connexion et en tapant le mot de passe root. Cela exécute le shell de root.
  • Connectez-vous en tant qu'utilisateur ordinaire, puis devenez root en exécutant suet en tapant le mot de passe root. Sur certains systèmes, cela nécessite d'être dans un groupe particulier (souvent appelé wheel); sur d'autres systèmes, toute personne connaissant le mot de passe root peut devenir root. Les systèmes utilisant PAM pour l'authentification pam_wheelpermettent de gérer le groupe de roues s'il en a un. Si vous spécifiez une commande avec su -c, elle est exécutée via le shell de root.
  • Connectez-vous en tant qu'utilisateur ordinaire, puis devenez root en exécutant sudoet en tapant votre propre mot de passe. Le compte utilisateur doit avoir reçu les pouvoirs sudo par un administrateur. Sauf restriction dans le sudoersfichier, vous pouvez exécuter n'importe quelle commande, quel que soit le shell de root.

Une manière traditionnelle de se protéger contre le shell de root n'est pas disponible est de définir un autre compte avec UID 0 et un shell différent ( toorest un nom traditionnel). Par exemple, si le shell de root est un exécutable lié dynamiquement (une bonne idée pour conserver la mémoire) et qu'une mise à niveau de la bibliothèque échoue, le shell de root peut être inutilisable. Le compte root alternatif aurait un exécutable lié statiquement, éventuellement avec des utilitaires communs intégrés tels que BusyBox .


5

Les réponses ci-dessus sont excellentes et j'ai appris en les lisant. Si vous ne vous souvenez pas des détails de ces approches et que cela ne vous dérange pas de redémarrer, vous pouvez toujours démarrer votre système en utilisant une distribution de CD live, monter la partition / puis éditer / etc / passwd et redémarrer. Pas aussi élégant que les solutions ci-dessus, mais plus facile à retenir.


Vous devez signaler les risques liés à la modification manuelle du /etc/passwdfichier. Autre que cela, bon point - je voulais juste ajouter la même suggestion à ma réponse.
rozcietrzewiacz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.