ライブラリのアップグレード中にアプリケーションを保護するメカニズムはありますか？

Question

@Kusalanandaが述べたように、通常、アップグレードは古いファイルを削除し、同じ名前の新しいファイルを作成することによって行われます。これにより、新しいinodeを含む新しいファイルが効果的に作成され、古いファイルが開いている間にシステムはそれを自由に使用できます。

単純化された例は次のとおりです。

rm /bin/cat
cp /new/version/of/cat /bin/cat

論理的な新しいファイルが作成され、cat実行中でも動作します。図書館も同じだ。_{（上記は例であり、実際の環境でファイルをアップグレードする信頼できる方法ではありません。）}

誰かが同じ名前の新しいバイナリを作成するのではなく、バイナリを変更してみることはできますか？この場合、少なくともLinuxは実際に使用している実行可能ファイルの変更をブロックします。

window 1 # ./cat
window 2 # echo foobar > cat
-bash: cat: Text file busy

しかし、動的にロードされたライブラリでは機能しないようです。

テスト用のコピーを作成し、libc.so.6次の使用時にゼロで埋めました。

window 1 /tmp/lib# LD_LIBRARY_PATH=/tmp/lib ldd ./cat
    linux-vdso.so.1 (0x00007ffcfaf30000)
    libc.so.6 => /tmp/lib/libc.so.6 (0x00007f1145e67000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1146212000)

window 1 /tmp/lib# LD_LIBRARY_PATH=/tmp/lib ./cat
foo
foo

Segmentation fault

（他のウィンドウで同時に、foosegfault以降、以前）

window 2 /tmp/lib# dd if=/dev/zero of=libc.so.6 bs=1024 count=2000

実際にオンラインでコードを編集したので、プログラム自体はこれについて何もできません。

（これはシステムによって異なる場合があります。私はDebian Jessie 8.5、Linux 3.16.7-ckt25-2+deb8u3でテストしました。特にIIRC Windowsシステムは、使用中のファイルが変更されるのを防ぐためにより積極的です。）

だから私のアイデアへのアップグレードは、一般的にファイルシステムの内部のおかげで問題を回避する方法で行われることが答えのようです。しかし、（Linuxでは）動的ライブラリの実際の破損を防ぐために行われたことはないようです。

Answer 1