La raison pour laquelle j'ai besoin de devenir en quelque sorte root sans taper Sudo
est que
error while loading shared libraries: libc.so.6:
cannot open shared object file: No such file or directory
J'ai utilisé Sudo
pour avoir Sudo mv /lib64/libc.so.6 /lib64/libc.so.6.bak
Parce que j'ai suivi certaines instructions pour pouvoir mettre à jour le lien symbolique vers libc-12.4.so
au lieu du libc-12.2.so
actuel par
LD_PRELOAD=./libc-2.14.so ln -s ./libc-2.14.so ./libc.so.6
Mais cela ne fonctionne pas avec Sudo
name__. Maintenant, j'ai peur de me déconnecter ou de redémarrer à la mort du système. Parce que je dois obtenir la permission root pour résoudre ce problème.
Je n'ai pas de disque de secours. Dans le pire des cas, je dois monter le disque dur sur une autre machine et le réparer.
S'il vous plaît aider.
$ Sudo bash -c "LD_PRELOAD=./libc-2.14.so ln -s ./libc-2.14.so ./libc.so.6"
Sudo: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
$ LD_PRELOAD=./libc-2.14.so Sudo LD_PRELOAD=./libc-2.14.so ln -s ./libc-2.14.so ./libc.so.6
Sudo: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
$ LD_PRELOAD=./libc-2.12.so Sudo LD_PRELOAD=./libc-2.12.so ln -s ./libc-2.12.so ./libc.so.6
Sudo: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
$ LD_PRELOAD=./libc-2.12.so ln -s ./libc-2.12.so ./libc.so.6
ln: creating symbolic link `./libc.so.6': Permission denied
libc.so.6
back.LD_PRELOAD
ne fonctionne pas avec les exécutables setuid. Toutefois, si vous le souhaitez, vous pouvez utiliser /bin/busybox
pour effectuer des sauvegardes de dernière minute (ne nécessitant pas l'exécution de commandes en tant qu'utilisateur root) avant le redémarrage. Il est possible de résoudre ce problème sans passer par un lecteur USB/CD/DVD en direct, mais vous devrez quand même redémarrer et je vous suggère d’en utiliser un.
LD_PRELOAD
ne fonctionne pas avec les commandes setuid.Actuellement, vous essayez de faire en sorte que Sudo
utilise la bibliothèque partagée renommée en définissant LD_PRELOAD
. Cela ne fonctionnera pas. Vous ne pouvez pas modifier les bibliothèques partagées avec Sudo
avec LD_PRELOAD
, et cela ne fonctionne pas non plus avec les alternatives à Sudo
. Si vous pourriez faire ceci, alors ce serait un bogue de sécurité extrêmement grave.
La façon dont Sudo
et pkexec
(et su
) fonctionnent pour vous permettre d’élever les privilèges est que ces exécutables ont le bit setuid défini 0 , ce qui les oblige à s’exécuter en tant qu’utilisateur propriétaire, qui est l’utilisateur root pour ces exécutables, et non l’utilisateur qui les exécute. Quand ils courent, ils valident très soigneusement ce que vous leur demandez de faire. De cette manière, à condition que leurs développeurs aient été suffisamment prudents, ils ne permettront aux utilisateurs d’exécuter que des actions qu’ils sont autorisés à effectuer.
LD_PRELOAD
n'a aucun effet pour les exécutables setuid exécutés par les utilisateurs autres que leurs propriétaires . C'est absolument vital pour la sécurité. Sinon, anybody pourrait créer sa propre bibliothèque et forcer un programme tel que Sudo
à l'utiliser, et n'importe qui pourrait alors obtenir les privilèges root. Vous pouvez utiliser LD_PRELOAD
pour exécuter des programmes non-setuid, et root peut l'utiliser pour exécuter à peu près n'importe quoi. Mais en tant qu'utilisateur non root, vous ne pouvez pas l'utiliser pour exécuter des programmes tels que Sudo
, pkexec
et su
qui sont setuid root.
Si vous déjà avez un shell racine en cours d'exécution, vous n'avez pas besoin de redémarrer. Mais même si le compte root est activé - c’est-à-dire même si vous aviez défini un mot de passe que vous pourriez utiliser pour vous connecter en tant que root avec une commande telle que su
--, vous ne pourrez toujours pas résoudre le problème sans redémarrage. Par exemple, su
dans Ubuntu requiert également libc.so.6
et est également setuid root afin que LD_PRELOAD
ne fonctionne pas non plus. 1 (Voir aussi Peter Cordes 's commentaires .)
Le problème ici est que les mécanismes disponibles pour effectuer des actions en tant que root exigent que vous exécutiez les exécutables setuid appartenant à root en tant que vous-même, mais LD_PRELOAD
n'a aucun effet dans cette situation. S'il n'était pas nécessaire d'exécuter des actions en tant que root - ou si un shell racine était ouvert -, vous pourrez le renommer facilement sans redémarrer. et aussi sans utiliser LD_PRELOAD
. Cela est dû au fait que les systèmes Ubuntu ont /bin/busybox
, qui est lié statiquement. It vous permet d’exécuter de nombreux outils * nix courants , y compris les commandes mv
et cp
. Vous pouvez exécuter /bin/busybox mv sourcedestination
ou simplement /bin/busybox sh
pour obtenir un shell dans lequel vous pouvez ensuite exécuter les commandes. Exécutez /bin/busybox
sans argument pour obtenir une liste des commandes prises en charge. Il a même une version de dpkg
!
Je mentionne busybox
principalement parce que, même si vous ne pourrez pas l'utiliser pour obtenir les privilèges root et restaurer le libc.so.6
, vous pouvez l'utiliser pour sauvegarder tous les fichiers que vous craignez de perdre. avant de redémarrer dans un environnement en direct. Je doute fort que vous voudrait que = perde quoi que ce soit , mais comme vous le craignez, vous voudrez peut-être Utilisez busybox
pour copier tous les fichiers importants, tels que les documents que vous avez créés ou modifiés depuis votre dernière sauvegarde, vers un autre emplacement.
Le redémarrage de la manière habituelle peut ne pas aller très loin, car les arrêts normaux impliquent en fait d'exécuter des programmes liés dynamiquement qui dépendent de libc.so.6
. Vous voudrez peut-être à utiliser Alt+SysRq+REISUB à redémarrer en toute sécurité . Ce n’est pas un moyen idéal d’arrêter, mais c’est probablement mieux qu’une tentative de redémarrage pratiquement inefficace suivie d’une réinitialisation matérielle. Une autre option consisterait à tenter de redémarrer l'ordinateur, puis à utiliser la méthode REISUB pour continuer. (Si vous souhaitez éteindre la machine plutôt que de la redémarrer, utilisez REISU O au lieu de REISU B. )
Lorsque vous démarrez à partir d'un environnement réel, il est facile de renommer le fichier. Vous n'avez pas besoin de chroot
ou de faire quelque chose d'extraordinaire. Montez simplement votre système de fichiers racine (ce que vous pouvez généralement faire en un clic dans le navigateur de fichiers, bien que vous puissiez utiliser la commande mount
si vous le souhaitez). Ensuite, dans un terminal, utilisez la commande mv
ou cp
pour restaurer libc.so.6
. Vous aurez besoin de Sudo
, mais cela fonctionne très bien dans un environnement réel.
Je sais que vous avez mentionné que vous n'aviez pas de disque de secours. Il serait difficile, voire impossible, de créer une clé USB amorçable sur ce système, où vous ne pouvez pas exécuter la plupart des programmes. (Vous pouvez utiliser busybox
pour copier et déplacer des fichiers. Il contient même une commande dd
, mais je ne vous recommanderais pas d'essayer de l'utiliser pour cela. Généralement, vous devez pouvoir exécuter dd
en tant que root pour créer un média en direct.) Peut-être que quelqu'un suggérera un moyen. Si vous avez une autre machine sur laquelle insérer le disque dur, espérons-le, vous pourrez le créer avec cette machine. Sinon, le mieux serait de demander à une connaissance d'en faire une.
Cependant, il y a est une alternative au démarrage depuis un média externe. 2 Vous devrez toujours redémarrer, mais vous n'avez pas besoin d'un système en direct. Je ne le recommande pas particulièrement car il est lourd; Utiliser un environnement live est plus facile. Vous pouvez faites-le sans si vous le souhaitez vraiment.
Comme Zanna l'avait déjà signalé dans des commentaires, le mode de secours == ne fonctionnerait pas car la plupart des programmes ont besoin de libc.6.so
(par exemple, /bin/bash
, qui fournit le shell, a besoin il). Mais vous pouvez démarrer le système avec /bin/busybox sh
as init en passant init=/bin/busybox sh
en tant qu'option de démarrage du noyau dans GRUB. 3 Il s’agit essentiellement de la même technique que le plus connu init=/bin/sh
(ou init=/bin/bash
) pour obtenir un shell racine, mais avec /bin/busybox sh
à la place du /bin/sh
normal, parce que /bin/sh
est lié de manière dynamique et nécessite libc.so.6
.
Si vous voulez le faire de cette façon, maintenez la gauche Shift pendant le (re) démarrage, le menu de démarrage GRUB apparaît. (Si Shift ne fonctionne pas, utilisez Esc.) A l’aide des touches fléchées, sélectionnez Options avancées pour Ubuntu et appuyez sur Entrée. Après cela, vous not appuyez sur Enter parce que cela amorcerait normalement plutôt qu'avec des options de démarrage personnalisées. Sélectionnez un noyau et appuyez sur e pour modifier ses options de démarrage temporairement. S'il y a plusieurs lignes et que votre curseur ne se trouve pas sur la ligne commençant par linux
, déplacez-le à l'aide des touches fléchées. Ajoutez init=/bin/busybox sh
à la fin de cette ligne et appuyez sur F10 pour le démarrer.
Vous devriez obtenir une invite de commande BusyBox. Vous devrez remonter le système de fichiers racine readwrite et renommer libc.so.6
afin qu'il ait le nom correct qu'il utilisait auparavant. Pour ce faire, exécutez ces commandes dans le shell BusyBox (les autres lecteurs possédant libc.so.6
à un emplacement différent devront ajuster le nom du répertoire transmis à la commande cd
):
mount -o remount,rw /
cd /lib64
mv libc.so.6.bak libc.so.6
Ensuite, je vous recommande de synchroniser toutes les écritures en cache sur le système de fichiers, de le remonter en lecture seule et de redémarrer:
sync
mount -o remount,ro /
reboot -f
(Sans -f
, la commande reboot
ne fonctionnera pas du tout dans cette situation, car aucun démon d'init approprié n'est en cours d'exécution.)
0 Pour ceux qui sont intéressés: lorsque ces programmes (tels que Sudo
) exécutent réellement votre commande ou créent un shell en tant qu'utilisateur root ou un autre utilisateur alternatif, vos ID utilisateur réel et effectif sont définis sur celui de l'utilisateur cible. Mais lorsque vous les exécutez, avant qu’ils ne le fassent, pendant qu’ils déterminent s’ils doivent vous autoriser à exécuter l’action que vous avez demandée, leur ID utilisateur effectif est celui de root, alors que leur véritable ID utilisateur est toujours le vôtre. Je mentionne cela pour remédier à une idée fausse commune sur la façon dont les ID utilisateur réels et efficaces fonctionnent dans des programmes tels que Sudo
; Si vous n'avez jamais entendu parler d'identifiants d'utilisateurs réels et efficaces, n'hésitez pas à ignorer cette note de bas de page.
1 Comme mentionné, busybox
dans Ubuntu est lié statiquement et ne repose pas sur libc.so.6
. Vous pourriez penser que vous pourriez utiliser ceci pour éviter le redémarrage, car busybox
offre une commande su
. Cependant, cela n’aide en rien, car lorsqu’il est installé, busybox
n’est pas setuid root. Pour permettre à un utilisateur non root de devenir root, su
doit être setuid root. La fonction utile de busybox su
est d'autoriser root == d'emprunter l'identité d'autres utilisateurs plutôt que de permettre à d'autres utilisateurs d'emprunter l'identité de root.
2 Zanna a grandement contribué à cette procédure, de même que all => le test effectué!
3 Cela réussit à passer sh
à busybox
même si vous pouvez vous attendre à ce qu'il soit interprété comme une option de démarrage ultérieure du noyau. Y compris les guillemets l'empêche de fonctionner. Notez également que, dans Ubuntu, l'exécutable busybox
lié de manière statique s'appelle simplement busybox
, not busybox-static
(bien que le package qui le fournit est appelé busybox-static
). Si vous avez désinstallé BusyBox lié de manière statique et installé BusyBox lié de manière dynamique, cette méthode ne fonctionnera pas, mais il est très peu probable que vous l'ayez fait.
Je connais le mot de passe root, il devrait donc exister un moyen de me laisser ouvrir un shell racine, mais il semble que je ne le puisse pas.
Vous ne pouvez pas utiliser le mot de passe root car (en renommant libc) vous avez brisé tous les moyens "normaux" de l'utiliser, y compris la connexion à un getty
sur une autre console de saisie. Si vous aviez un su ou un Sudo lié statiquement , vous pouvez l'utiliser pour exécuter busybox mv
ou (dans le cas général d'obtenir un shell racine qui fonctionne), utilisation
LD_PRELOAD=whatever LD_LIBRARY_PATH=whatever static-su --preserve-environment
pour transmettre cet environnement personnalisé à un bash s'exécutant en tant que root
Les binaires Setuid eux-mêmes ne peuvent pas faire confiance à l'environnement fourni par un utilisateur qui les exécute, mais (s'ils fonctionnent) peuvent transmettre l'environnement si vous l'avez demandé et que vous connaissez le bon mot de passe pour authentifier cette opération.
Mais comme vous n'avez pas de binaire setuid statique qui puisse authentifier votre demande pour transmettre un environnement personnalisé à un processus exécuté en tant que root
, vous devez simplement utiliser votre accès physique pour redémarrer dans un environnement qui vous permet de modifier le système de fichiers racine. par exemple. un DVD ou une clé USB, ou démarrez votre système habituel avec init=/bin/busybox sh
(voir la réponse de @ Eliah).
Si vous n’avez pas de support de récupération, créez quelque chose d’amorçable sur un autre ordinateur, en utilisant une image Live Ubuntu ou l’une des images d’amorçage de récupération appropriées pour réparer divers systèmes d’exploitation et exécuter des diagnostics du matériel ( voici une revue de 5 différents ). (Celles-ci sont souvent plus petites qu’un Ubuntu en direct, ne prenant par exemple que 700 Mo environ sur une clé USB.)
Vous pouvez configurer une clé USB pour qu’elle soit amorçable avec l’un de ces éléments (ou Ubuntu) tout en pouvant l’utiliser pour le stockage de fichiers normal; vous n'avez pas besoin de dédier une clé USB entière à une image amorçable. (Les moyens les plus simples de créer une clé USB active effacent le contenu précédent et ne le laissent parfois même pas utilisable pour stocker des fichiers, cependant.)
Une autre option consiste à faire entrer initramfs dans un shell avant d'exécuter pivot_root
et d'exécuter le init=
que vous avez transmis sur la ligne de commande du noyau. Cela ne dépend d'aucun contenu de la racine FS elle-même. Vous n’avez peut-être pas d’éditeur du tout, mais vous avez cat
et une redirection, ainsi que mv et ln. (cat > /mnt/root/etc/something
). Si le problème que vous devez résoudre n'est pas trivial, vous devriez probablement démarrer avec quelque chose de plus puissant!
Cela se produit automatiquement dans certains cas d'échec de démarrage, par exemple. si la détection RAID échoue ou que quelque chose empêche la fs racine de monter (même en lecture seule). ( Ubuntu 15.10 - "Shell intégré à BusyBox (initramfs)" à chaque démarrage )
Vous pouvez y arriver avec break=bottom
sur la ligne de commande du noyau à déposer dans le shell busybox du initramfs, après avoir effectué la plupart des opérations (chargement de modules et montage de la racine FS en lecture seule), mais avant d'exécuter le nom réel init
. break=premount
arrête plus tôt; voir ce lien ou /usr/share/initramfs-tools/init
pour plus de détails.