スティッキービットは、ファイルに適用されたときに元々何をしましたか?


65

さまざまな場所で、今日の機能ディレクトリへの書き込み許可に影響を与え、制限付き削除フラグとして機能するため、今日の「スティッキービット」は完全に誤った呼び名であると非難されています

AskUbuntuの回答で、回答者は「スティッキービットは通常ディレクトリに適用される」と書いています。実際、現代のシステムは実際にはファイルに適用しないように見えますが、昔は通常の場合、ディレクトリではなく(実行可能なプログラムイメージ)ファイルに適用されていました。(ファイルの現代的な使用の不足に関しては、「スティッキービットは現在のファイルシステムでは使用されていませんか?」に関連する質問があります。)

これは質問を促しました:

実行可能ファイルに適用されたスティッキービット何をしましたか?それはsetuidのようなものでしたか?

過去形に注意してください。これはスティッキービットの仕組みではありませんか?今。それが当時の動作方法です。


3
「実際、現代のシステムは実際にはファイルに適用しないように見えることを観察しました」は、一部のシステムにのみ当てはまることを指摘したいと思います。 付箋に関するウィキペディアのページ、「現在、この動作はHP-UXおよびUnixWareでのみ有効です。」さまざまな実装を示すチャートがあります。一般的なスレッドは、オペレーティングシステムがそれを無視するか、メモリ/スワップなどを識別するために処理するオペレーティングシステムです。処理する必要があります。使用方法の詳細は、オペレーティングシステムによって異なります。たとえば、JdeBPの答えのようなスティッキービットを使用したLinuxシステムはありません。
TOOGAM

回答:


91

いいえ、スティッキービットはset-UIDまたはset-GIDフラグとは異なりました。プロセス資格情報の変更には影響しませんでした。

スティッキービットがしたことは、プログラムテキストを「スティッキー」にすることでした。もともとそれは誤名ではありませんでした。

背景:プログラム画像セクションと共有テキスト

本質的に、実行可能なファイル形式の詳細に深く入り込むことなく(本を埋めることができます)、プログラムを実行するためにメモリに直接読み込まれるプログラムイメージファイルの部分は、マシンコード、定数、スタートアップで構成されます(ゼロで初期化されていない)変数の値、およびゼロで初期化されている変数と初期化されていない変数の(ある形式または別の形式の)空白。

これらは「セクション」と呼ばれるコレクションにグループ化され、従来の名前が付けられています。マシンコードと(時には)定数は、プログラムイメージの「テキスト」セクションとしてよく知られているものを形成します。同様に、ゼロ以外の初期化変数は「データ」セクションです。そして、ゼロで初期化された変数と初期化されていない変数は「bss」(それ自体の背後にある民間伝承の歴史全体を持っている名前)です。

プロセスにプログラム実行可能イメージファイルがロードされている場合、さまざまな部分(テキスト、データ、およびbss)がイメージファイルのコンテンツから初期化されます。

「テキスト」セクションの特別な点は、マシンコード(および定数)がほとんど常に書き込まれないことです。その実行可能イメージファイルが読み込まれたすべての実行プロセスの仮想メモリイメージ間で共有される可能性があります。プログラムテキストを共有できる正確なシナリオは、この答えの範囲外であり、ローダー修正アップi等性やアドレススペースレイアウトIDなどが含まれます。人々は、この主題についての本も書くことができます。☺

共有テキストは、カーネルで採用されている最適化です。実行中の単一のプログラムイメージのすべてのインスタンスが独自のメモリイメージを持つ必要がなくなり、まったく同じマシンコード(および定数)の複数のコピーで貴重な物理メモリを消費します。

付箋

しかし、テキストを共有するよりもさらにうまくやることができます。明らかに、特定の共有テキストプログラムイメージを使用している実行中のプロセスが常に少なくとも1つある場合、カーネルは、プログラムの新しいインスタンスが実行されるときに、既存の共有テキストセグメントに新しいプロセスの仮想メモリ空​​間を単純にアタッチします。インスタンス(たとえば)ほとんど常にあります/bin/login/bin/sh実行しているどこかの中規模システムで、ログインプログラムまたは単にカーネルが既にメモリにロードされた彼らのテキスト・セグメントのロードされたコピーに添付することができ、デフォルトのシェルのように新しいインスタンスが。

スティッキーテキストは、このアイデアを、現在プロセスが実行されていないプログラムイメージに拡張します。実行可能イメージファイルがスティッキーテキストとしてマークされている場合、使用する最後のプロセスが終了した後、カーネルはテキストセグメントを保持します。プログラムの別のインスタンスがすぐに実行され、セグメントに再びアタッチできることを期待して。

初期のUnicesでは、ロードされたスティッキーテキストセグメントは、プロセスがアタッチされていないときに、ストレージをスワップするためにスワップアウトされました。(後のユニックスは、このためにスワップの使用を停止しました。)名前save saved textでこれを聞いたことがあるかもしれません。

もちろん、プログラムイメージにスティッキーテキストビットを設定することは、注意して行う必要があります。どのプログラムがそれから利益を得るかは、マシンが一般的に使用されるものに依存します。また、現在接続されていないテキストセグメントはカーネルリソースを占有します。つまり、システムに保持できるテキストセグメントの数には実際的な制限があります。そのため、通常はスーパーユーザー権限が必要な操作です。

でええでで

スティッキーテキストの操作の根底にある多くの仮定がありますが、それはもはや真実ではありません。事前に作成されたセグメントをスワップストレージから読み取ることは、実際の実行可能イメージファイルからの単純な要求ページングよりも必ずしも高速ではありません。ファイルシステム形式は、ランダムな(シーケンシャルではなく)読み取りパターンの方が良くなりました。デマンドページング自体の出現は、ユニファイドキャッシュ、共有ライブラリ検索の違いによる非べき等の外部修正、アドレス空間レイアウトのランダム化などのように、状況を変化させます。

実行可能なプログラムイメージのスティッキーテキストビットの時代は過ぎ去りました。実行可能なプログラムイメージの明示的なスティッキテキストマーカーフラグは、たとえば1980年代半ばに4.3BSDの作者によって廃止されたと見なされていました。

参考文献

  • モーリス・J・バッハ(1986)。 UNIXオペレーティングシステムの設計。プレンティスホール。ISBN 9780132017992。

1
とてもいい答えです!今日、私は何かを学びました。:)
アンドレアスヴィーゼ

私も:)これTSRは、DOSの時代に私が知っていた「終了して常駐する」ことによく似ています。ただし、これは通常、後で実行される他のプロセスが呼び出す必要があるデバイスドライバーのようなものであり、世界がマルチスレッド/マルチプロセスOSに移行するとおそらく廃止されます。
スティーブ

1
これは素晴らしい答えです。の起源についてはどこで読むことができbssますか?

1
TSRは実際には類似していません。IBM + Microsoftの世界の類似物については、標準モードの DOS + Windows 3.x および16ビットOS / 2バージョン1.xを参照してください。EXEおよびDLL のCODEセグメント(およびOS / 2読み取り専用DATAセグメント)は、実行中のすべてのプログラム間で(通常)共有されます。32ビットOS / 2バージョン2.xと386拡張モードがセグメントスワッピングをデマンドページ仮想メモリに置き換えたため、「粘着性」に相当するものはありません。ほぼ同じ方法でセグメンテーションの粘着性が必要です。
JdeBP

3
@JdeBP:「スティッキービットはsetuidに似ていましたか?」という質問 かなり広範かつ不正確です。私は、答えは「まあ、やや複雑です」と主張します。なぜなら、下位9ビットが似ていて、特定のユーザーがファイルに対して特定の操作を実行できるかどうかに影響するからです。また、set-UID、set-GID、およびstickyビットは、操作が許可されているかどうかに関係なく、代わりに(具体的には、実行操作)の実行方法の一部をモデレートするという点で似ていました。
Gマン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.