web-dev-qa-db-fra.com

Répertoires déplacés accidentellement sous la racine

J'ai accidentellement lancé cette commande

Sudo mv /* /applications/minced/

au lieu de

Sudo mv ./* /applications/minced/

C'est tout ce qui reste dans le répertoire racine

$ /
applications/ dev/          proc/         run/          sys/          tmp/

J'ai toujours une connexion ssh active sur le serveur. J'ai essayé d'appeler mv, Sudo et chmod... directement à partir de /applications/minced/bin/ ou /applications/minced/usr/bin/, mais rien ne fonctionne, même si je peux les localiser à l'aide de achèvement automatique du chemin.

$ /applications/minced/bin/ls
-bash: /applications/minced/bin/ls: No such file or directory

J'ai lu Rétablir récursivement le répertoire racine de déplacement , mais monter le système sous LiveCD n'est pas une option pour moi puisqu'il s'agit d'un VPS, et non d'une machine physique. Des idées?

Mettre à jour

J'ai compris que cela était dû à des problèmes de liaison de bibliothèque, alors je l'ai fait

$ export LD_LIBRARY_PATH=/applications/minced/lib/x86_64-linux-gnu/
$ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/bin/mv /applications/minced/* /

Évidemment, j'ai rencontré des problèmes de permission. L'appel de Sudo avec l'éditeur de liens lève cette erreur

$ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/usr/bin/Sudo ...
Sudo: effective uid is not 0, is /applications/minced/usr/bin/Sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Comme suggéré par Barafu Albino, j'ai essayé d'appeler su avec busybox (.../bin/busybox su -), mais jette su: must be suid to work properly. Je suppose que cela se produit parce que su ne peut pas localiser /etc/passwd et /etc/shadow. On dirait que j'ai complètement foiré le système.

sshdata-recoveryrootmv
7
Eli Korvigo

Vos applications ne peuvent pas s'exécuter car elles veulent trouver des bibliothèques et celles-ci sont également mal placées. Essayez d’utiliser busybox directement.

bin/busybox ls

devrait fonctionner comme ls et ainsi de suite.

10
Barafu Albino

Permet de faire une autre approche. Je suppose que vous ne connaissez pas le vrai mot de passe root. Voici une liste des bibliothèques dont Sudo a besoin:

linux-vdso.so.1 =>  (0x00007ffea6be9000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fbbad17b000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fbbacf78000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbbacd74000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbbac9aa000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fbbac73d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbbad5c5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbbac51f000)

Voici une liste des fichiers du package Sudo (uniquement ceux pertinents):

/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/Sudo.service
/usr
/usr/lib
/usr/lib/Sudo
/usr/lib/Sudo/system_group.so
/usr/lib/Sudo/sudo_noexec.so
/usr/lib/Sudo/sudoers.so
/usr/lib/Sudo/group_file.so
/usr/lib/Sudo/sesh
/usr/bin
/usr/bin/sudoreplay
/usr/bin/Sudo

Essayez de déplacer les bibliothèques vers le binaire, dans le même dossier. Peut-être que ça va marcher. su a moins de dépendances, mais nécessite de connaître le vrai mot de passe root.

4
Barafu Albino

Je viens de rencontrer ce problème exactement comme ce post. J'utilise un serveur Ubuntu qui a un utilisateur root désactivé et utilise Sudo pour exécuter les commandes root. donc je ne peux pas me connecter avec l'utilisateur root par hasard, la seule façon pour moi dans l'instance est de faire fonctionner le Sudo. malheureusement, les heures ont passé, j'ai échoué, c'est dommage.

Et pour les utilisateurs qui peuvent se connecter avec la racine, je suppose que vous avez oublié de mentionner un autre moyen qui pourrait être beaucoup plus simple: busybox sulogin

0
yanyingwang