見つからない/名前が変更されたlibc.so.6を修正するにはどうすればよいですか？
Sudoを入力せずに何らかの方法でルートになる必要がある理由は、
error while loading shared libraries: libc.so.6:
cannot open shared object file: No such file or directory
Sudoを使用してSudo mv /lib64/libc.so.6 /lib64/libc.so.6.bakを取得しました
なぜなら、現在のlibc-12.4.soの代わりにlibc-12.2.soへのシンボリックリンクを更新できるように、いくつかの指示に従ったからです。
LD_PRELOAD=./libc-2.14.so ln -s ./libc-2.14.so ./libc.so.6
しかし、これはSudoを使用して機能しません。今、私はログアウトするか、システムが死ぬまで再起動することを恐れています。これを修正するにはルート権限を取得する必要があるためです。
レスキューディスクがありません。最悪の場合、ハードドライブを別のマシンにマウントして修正する必要があります。
助けてください。
$ 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
ライブUSB（またはCD/DVD）から起動し、libc.so.6の名前を変更してください。
LD_PRELOADは、setuid実行可能ファイルでは機能しません。ただし、必要に応じて、/bin/busyboxを使用して、再起動する前に直前のバックアップ（rootとしてコマンドを実行する必要はありません）を実行できます。ライブUSB/CD/DVDを使用せずにこれを修正することは可能ですが、それでも再起動する必要があります。使用することをお勧めします。
LD_PRELOADはsetuidコマンドでは機能しません。
現在、LD_PRELOADを設定して、Sudoに名前を変更した共有ライブラリを使用させようとしています。これは機能しません。 Sudoのリンク先の共有ライブラリをLD_PRELOADで変更することはできません。また、Sudoの代替のいずれでも機能しません。couldでこれを行うと、非常に深刻なセキュリティバグになります。
Sudoおよびpkexec（およびsu）が特権を昇格させる方法は、これらの実行可能ファイルに setuidビット が設定されていることです。、それらを所有するユーザーとして実行します。これらの実行可能ファイルは、実際に実行するユーザーではなく、ルートユーザーです。それらが実行されるとき、彼らはあなたが彼らに何をするように頼んでいるかを非常に注意深く検証します。このように、開発者が十分な注意を払っていれば、ユーザーは実行を許可されたアクションのみを実行できます。
LD_PRELOADは効果がない ユーザーが実行するsetuid実行可能ファイルの場合 所有者以外 。これは絶対にセキュリティに不可欠です。そうしないと、anybodyが独自のライブラリを作成し、Sudoのようなプログラムでそれを使用するように強制できます。 LD_PRELOADを使用して非setuidプログラムを実行でき、rootはそれを使用してほぼすべてを実行できます。ただし、非rootユーザーとして、setuid rootであるSudo、pkexec、suなどのプログラムを実行することはできません。
alreadyでルートシェルが実行されている場合は、再起動する必要はありません。ただし、rootアカウントを有効にしている場合、つまり、suなどのコマンドを使用してrootとしてログインするために使用できるパスワードが設定されている場合でも、それなしでは問題を解決することはできません再起動します。たとえば、Ubuntuのsuにはlibc.so.6も必要であり、setuid rootでもあるため、LD_PRELOADも動作しません。1 （ Peter Cordes の comments も参照してください。）
ここでの問題は、アクションas rootを実行するために利用可能なメカニズムでは、rootが所有するsetuid実行可能ファイルを自分で実行する必要があるが、LD_PRELOADはその状況では効果がないことです。ルートとしてアクションを実行する必要がなかった場合-またはすでにルートシェルを開いていた場合-そして、再起動せずに簡単に名前を変更することができますLD_PRELOADを使用します。これは、Ubuntuシステムには/bin/busyboxがあり、これは静的にリンクされているためです。それ 一般的な* nixツールの多くを実行できます （mvおよびcpコマンドを含む）。 /bin/busybox mv sourcedestinationを実行するか、/bin/busybox shだけを実行してシェルを取得し、そこでシェルでコマンドを実行できます。引数なしで/bin/busyboxを実行して、サポートされているコマンドのリストを取得します。 dpkgのバージョンもあります！
ファイルをバックアップし（必要な場合）、ライブ環境で再起動できます。
主にbusyboxに言及します。これは、root権限を取得してlibc.so.6を復元するために使用することはできませんが、canを使用して、再起動する前に失う可能性のあるファイルをバックアップするためですライブ環境に。 私はあなたがwould何かを失うことを非常に疑います、しかしあなたは心配しているので、あなたはbusyboxを使用したいかもしれません重要なファイル（前回のバックアップ以降に作成または変更したドキュメントなど）を別の場所にコピーします。
通常のシャットダウンには、実際にはlibc.so.6に依存する動的にリンクされたプログラムの実行が含まれるため、通常の方法での再起動はそれほど遠くないかもしれません。 使用する場合があります Alt+SysRq+REISUB to 安全に再起動 。これはシャットダウンするのに理想的な方法ではありませんが、ほとんどの場合、リブートしてハードリセットを実行するよりも効果的でない方法よりも良いでしょう。別のオプションは、再起動を試みてから、REISUBメソッドを使用して残りの方法を取ることです。 （マシンを再起動するのではなく電源をオフにする場合は、REISUBではなくREISUOを使用します。）
ライブ環境からブートする場合、ファイルの名前変更は簡単です。 chrootや特別なことをする必要はありません。ルートファイルシステムをマウントするだけです（通常、ファイルブラウザでワンクリックで実行できますが、必要に応じてmountコマンドを使用できます）。次に、ターミナルでmvまたはcpコマンドを使用して、libc.so.6を復元します。 Sudoが必要になりますが、ライブ環境では問題なく機能します。
レスキューディスクがないと言ったことは知っています。ほとんどのプログラムを実行できないシステム上で起動可能なライブUSBを作成することは、おそらく不可能です。 （busyboxを使用してファイルをコピーおよび移動できます。また、ddコマンドもありますが、そのために使用することはお勧めしません。通常、ライブメディアを作成するにはrootとしてddを実行できる必要があります。）おそらく誰かが方法を提案するでしょう。ハードディスクを入れる別のマシンがある場合は、そのマシンで作成できることを願っています。そうでない場合、あなたの最善の策は、それを作るために知人に尋ねることです。
ライブCD/DVD/USBを使用しない方法もありますが、それでも再起動する必要があります。
ただし、isが外部メディアからの起動に代わるものです。2 まだリブートする必要がありますが、稼働中のシステムは必要ありません。これは面倒なので、特にお勧めしません。ライブ環境を使用する方が簡単です。ただし、本当に必要な場合は、canなしで実行します。
Zanna が以前にコメントで指摘したように、rescue modeは機能しません。ほとんどのプログラムがlibc.6.soを必要とするためです（たとえば、シェルを提供する/bin/bashは必要です）。ただし、/bin/busybox shを init としてシステムをブートするには、init=/bin/busybox shをGRUBのカーネルにブートオプションとして渡します。3 これは基本的に、ルートシェルを取得するためのより一般的なinit=/bin/sh（またはinit=/bin/bash）と同じ手法ですが、/bin/busybox shは動的にリンクされ、/bin/shを必要とするため、通常の/bin/shではなくlibc.so.6を使用します。
このようにしたい場合は、左を押したままにします Shift （再）起動中にキーを押すと、GRUB起動メニューが表示されます。 （もし Shift 動作しない、使用する Esc。）矢印キーを使用して、Ubuntuの詳細オプションを選択し、Enterを押します。この後、wo n'tを押します Enter カスタムブートオプションではなく、通常の方法でブートするためです。カーネルを選択して押します e 起動オプションを一時的に編集します。複数の行があり、カーソルがlinuxで始まる行にない場合は、矢印キーでそこに移動します。 init=/bin/busybox shをその行の最後に追加してを押します F10 それを起動します。
BusyBoxシェルプロンプトが表示されます。ルートファイルシステムを再書き込みして、libc.so.6の名前を変更し、以前の正しい名前に変更する必要があります。これを実現するには、BusyBoxシェルで次のコマンドを実行します（別の場所にlibc.so.6を持っている他の読者は、cdコマンドに渡されるディレクトリ名を調整する必要があります）。
mount -o remount,rw /
cd /lib64
mv libc.so.6.bak libc.so.6
次に、キャッシュされた書き込みをファイルシステムに同期し、読み取り専用で再マウントし、再起動することをお勧めします。
sync
mount -o remount,ro /
reboot -f
（-fがなければ、この状況ではrebootコマンドはまったく機能しません。適切なinitデーモンが実行されていないためです。）
これらのプログラム（Sudoなど）が実際にコマンドを実行するか、rootまたは他の代替ユーザーとしてシェルを作成すると、実際のユーザーIDと有効なユーザーIDの両方がターゲットユーザーのIDに設定されます。しかし、あなたがそれらを実行する前に、彼らはこれを行う前に、彼らがあなたがあなたが求めた行動を実行することを許可すべきかどうかを決定している間、彼らの実際のユーザーIDはまだあなたのものである間、彼らの実効ユーザーIDはrootのものです。 Sudoのようなプログラムで実際の有効なユーザーIDが機能する方法に関する一般的な誤解に対処するために、これに言及します。実際の効果的なユーザーIDを聞いたことがない場合は、この脚注を無視してください。
1前述のとおり、Ubuntuのbusyboxは静的にリンクされており、libc.so.6に依存しません。 busyboxにはsuコマンドが用意されているため、これを使用して再起動を回避できると考えるかもしれません。ただし、これは何の助けにもなりません。インストール時に、busyboxはsetuid rootではないためです。非rootユーザーがrootになることを実際に許可するには、sumustをsetuid rootにします。 busybox suの便利な機能は、他のユーザーがルートを偽装できるようにするのではなく、rootが他のユーザーを偽装できるようにすることです。
2 Zannaはこの手順に大きく貢献し、allのテストも行いました！
3これは、後続のカーネルブートオプションとして解釈されると予想される場合でも、shをbusyboxに渡すことに成功します。引用符を含めると、機能しなくなります。また、Ubuntuでは、静的にリンクされたbusybox実行可能ファイルは、単にbusybox、notbusybox-staticと呼ばれます（ただし、packageはそれを提供しますisはbusybox-staticと呼ばれます）。静的にリンクされたBusyBoxをアンインストールし、動的にリンクされたBusyBoxをインストールした場合、このメソッドは機能しませんが、それを行ったことはほとんどありません。
私はルートパスワードを知っているので、ルートシェルを開く方法があるはずですが、できないようです。
（libcの名前を変更することにより）別のテキストコンソールでgettyにログインするなど、使用できるすべての「通常の」方法を破ったため、rootパスワードを使用できません。 suまたはSudoが静的にリンクされている場合、それを使用してbusybox mvを実行できます。ルートシェル）、使用
LD_PRELOAD=whatever LD_LIBRARY_PATH=whatever static-su --preserve-environmentは、このカスタム環境をルートとして実行されているbashに渡します
Setuidバイナリ自体は、それらを実行しているユーザーが提供する環境を信頼できませんが、（動作する場合）環境を渡すことができますif要求し、正しいパスワードを知っているその操作を認証します。
しかし、rootとして実行されているプロセスにカスタム環境を渡す要求を認証できる静的setuidバイナリがないため、物理アクセスを使用して、ルートFSを変更できる環境に再起動する必要があります。例えばDVDまたはUSBスティック、またはinit=/bin/busybox shで通常のシステムを起動します（@Eliahの回答を参照）。
回復メディアがない場合は、UbuntuライブイメージまたはさまざまなOSの修復とハードウェア診断の実行に適したいくつかの回復ブートイメージのいずれかを使用して、別のコンピューターで起動可能なものを作成します（ こちら5種類のレビュー ）。 （これらは多くの場合、ライブUbuntuよりも小さく、たとえばUSBスティックで約700MBしか占有しません。）
これらのいずれか（またはUbuntu）で起動可能なUSBスティックをセットアップし、通常のファイルストレージに使用することができます。 USBスティック全体をブータブルイメージ専用にする必要はありません。 （ライブUSBスティックを作成する最も簡単な方法は、以前のコンテンツを吹き飛ばし、ファイルを保存するために使用できないままにすることさえあります。）
別のオプションは、pivot_rootを実行してカーネルに渡したinit=を実行する前に、initramfsをシェルにドロップすることですコマンドライン。これは、ルートFS自体の内容に依存しません。エディターはまったくないかもしれませんが、catとリダイレクト、およびmvとlnがあります。 （cat > /mnt/root/etc/something）。修正する必要がある問題が自明でない場合は、おそらくより強力なものを起動する必要があります！
これは、いくつかのブート障害の場合に自動的に発生します。 RAIDの検出に失敗した場合、またはルートfsがそもそもマウントされない場合（読み取り専用であっても）。 （ buntu 15.10-ブートごとに「BusyBox組み込みシェル（initramfs）」 ）
これは、カーネルコマンドラインでbreak=bottomで発生させることができます initramfsのbusyboxシェルにドロップします、ほとんどのことを行った後（モジュールをロードしてルートFSを読み取り専用でマウント）、実際のinitを実行する前。 break=premountは早く停止します。詳細については、そのリンクまたは/usr/share/initramfs-tools/initをご覧ください。