単一の基本プロセスからのみソースファイルを削除する方法はありますか?
他のプロセスではこれを読み取って修正できますが、削除することはできません。プロセスはコンテンツを空にすることができますが、これらのプロセスは人間のやりとりを通じてコンテンツにアクセスするため、これは問題ではありません。
重要なのは、基本プロセスがinodeへのアクセスを失うべきではないということです。 Ext4はそうですか?絶対パスに関するものではなく、インデックスノードに関するものです。そうですか?
一部のプロセスでは、安全な書き込みを提供するために新しいファイルを書き、元のファイルを削除または名前を変更し、新しいファイルの名前を元のファイルに変更して元のファイルを削除しますが、元のinodeが失われ、基本プロセスがファイルに追加するときに再生成しようとしません。 (プロセスは同じinodeから新しいコンテンツをバックアップ、比較、書き込むことができますが、そうではありません。)
主なプロセスはどこにも書かれていないようです。
答え1
単一の基本プロセスからのみソースファイルを削除する方法はありますか?
習慣。ファイルアクセスは、各プロセスではなくユーザーIDとグループIDに基づいて行われます。
もちろん、プロセスに別々のグループIDを付与することも、独自のユーザーとして実行することもできます。これにより、他のプロセスと同様に、別々の「カテゴリ」に配置され、別々の権限を定義できます。
これらのプロセスは人間の相互作用を介してアクセスされるため、問題はありません。
まあ、それはそれほど論理的ではありません。対話型プロセスは非対話型プロセスとまったく同じである可能性があり、通常は少なくともそれほどのバグがあります。
一部の手順では、安全な書き込みを提供するために新しいファイルを作成し、元のファイルを削除または名前を変更し、新しいファイルを元のファイルに名前を変更して元のファイルを削除します。
いいえ!逆の場合が発生します。新しいファイルに書き込み、新しいファイルの名前を古いファイルの名前に変更します。これは原子的なので、そうすることです。古いファイルは決して削除されません!プロセスの瞬間ごとに正確な名前のファイルがあります。
すべてのファイルアクセスについては、以下を参照してください。何もないしかし、追加単一write
データの場合、この原子交換は唯一の安全な方法です! (ロック構造で本当に珍しい操作を実行したい場合を除き、ほとんどのファイル形式はそのような操作を許可しません!)
したがって、自分が解決していると思う問題は何でも問題ありません。必要なものを達成するには、別の方法を見つける必要があります。
同じinodeに新しいコンテンツを書き込む
時には「inode」という言葉が消えてほしい!これは実際にはファイルシステムのディスクフォーマットの実装の詳細であり、ユーザーはそれを使用する必要があります。いいえ 処理する必要があります。本当です。ファイルシステムを開発しない限り、inodeに興味を持ち始めるとき、おそらく何か間違ったことをしているでしょう。
答え2
「明白な」答えは「あいまいさによるセキュリティ」(STO)です。つまり、他のプロセスがそれを知らないようにします。 名前ファイル。
この質問には、ソフトウェアアーキテクチャの文脈や大きな画像が欠けています。 「メインプロセス」という用語を使用すると、 親ファイルを開き、ファイル記述子を渡すプロセス 子供 プロセス。 「他のプロセス」が独立してファイルを開く場合は、ファイル名を知る必要があり、この方法は使用できません。同様に、ファイル名がハードコードされていて「よく知られている」場合、このアプローチは役に立ちません。
可変ファイル名を持つ親/子アーキテクチャがある場合は、子プロセスで名前を秘密にしてください。
可能 探すファイルの場合、対応する inode 番号がわかっている場合。パブリックに読み取れないディレクトリにファイルを配置することで、この攻撃パスをブロックできます。
答え3
次のことができます。
まず、他のすべてのプロセス(基本プロセスを除く)がすべての種類のファイルに書き込めないように無効にします。たとえば、次のようになります。
mv my_precious_file my_precious_file.original
次に、ファイルへのハードリンクを作成します。
sudo ln my_precious_file.original my_precious_file.copy
第三に、信頼できないサブプロセスがハードリンクされたファイルにアクセスできるようにします。
# DUMMY example, this is not code you shall execute,
# it's purpose is to show that a process might delete the original file,
# but now it can only delete the hard linked "copy" and not the "original"
# "Haha I'm a not trustworthly process." (Some people don't understand.)
cp my_precious_file.copy /dev/null && rm my_precious_file.copy
あなたのサブプロセスは依然としてハードリンクの「コピー」を削除することができますが、「ソース」は「変更されていない」状態のままです。
ハードリンクの「コピー」が「削除」されている場合は、「再作成」するだけです。