スティッキービットはどのように機能しますか？

これはおそらく、人々がいつも台無しにする私の最も厄介なことの1つです。 SUID / GUIDビットとスティッキービットは2つのまったく異なるものです。

man chmodを実行すると、SUIDとスティッキービットについて読むことができます。 のマニュアルページもここにあります。

背景

抜粋

文字 rwxXst のファイルモードビットを選択します影響を受けるユーザー：読み取り（r）、書き込み（w）、実行（またはディレクトリの検索）（x）、ファイルがディレクトリであるか、一部のユーザーの実行権限を既に持っている場合にのみ実行/検索（X）、実行時にユーザーまたはグループIDを設定します、制限付き削除フラグ、またはスティッキービット（ t）。

SUID / GUID

上記のマニュアルページとはつまり、ユーザーのオクタル（rwxの第1グループ）とグループオクタル（rwxの第2グループ）のrwxrwxrwxでxビットがとる位置は、xがsになる追加の状態を取ることができます。これが発生すると、実行時にこのファイルが実行されます（シェルスクリプトだけでなくプログラムの場合）。ファイルの所有者またはグループのアクセス許可で実行されます。

したがって、ファイルがrootによって所有されている場合SUIDビットがオンになっていると、プログラムはrootとして実行されます。通常のユーザーとして実行しても、GUIDビットにも同じことが当てはまります。

抜粋

SETUIDおよびSETGIDビット

chmodは、ファイルのグループIDがクリアする場合、通常のファイルのset-group-IDビットをクリアします。ユーザーが適切な特権を持っていない限り、ユーザーの実効グループIDまたはユーザーの補足グループIDの1つと一致しません。追加の制限により、MODEまたはRFILEのset-user-IDビットとset-group-IDビットが無視される場合があります。この動作は、基盤となるchmodシステムコールのポリシーと機能によって異なります。疑わしい場合は、基になるシステムの動作を確認してください。

chmodは、特に指定しない限り、ディレクトリのset-user-IDビットとset-group-IDビットを保持します。シンボリックでビットを設定またはクリアできます。 u + sやgsなどのモードで、数値モードでビットを設定できます（ただし、クリアはできません）。

SUID / GUIDの例

no suid / guid -ビット rwxr-xr-x のみが設定されます。

$ ls -lt b.pl -rwxr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

suid &ユーザーの実行可能ビット有効（小文字）-ビット rwsr-xrx が設定されます。

$ chmod u+s b.pl $ ls -lt b.pl -rwsr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

suidが有効&実行可能ビットが無効（大文字S）-ビット rwSr-xr-x が設定されています。

$ chmod u-x b.pl $ ls -lt b.pl -rwSr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

guid &グループの実行可能ビット有効（小文字s）-ビット rwxr-sr-x が設定されます。

$ chmod g+s b.pl $ ls -lt b.pl -rwxr-sr-x 1 root root 179 Jan 9 01:01 b.pl 

ガイドが有効&実行可能ビットが無効（大文字S）-ビット rwxr-Sr-x が設定されます。

$ chmod g-x b.pl $ ls -lt b.pl -rwxr-Sr-x 1 root root 179 Jan 9 01:01 b.pl 

スティッキービット

上のスティッキービット一方、tは、/tmpディレクトリのように示されます：

$ ls -l /|grep tmp drwxrwxrwt. 168 root root 28672 Jun 14 08:36 tmp 

このビットは、それが実際に意味することを考えると、常に「制限付き削除ビット」と呼ばれるべきでした。このモードビットを有効にすると、ユーザーが所有者であるファイル&ディレクトリのみを削除できるようにディレクトリが作成されます。

抜粋

制限付き削除フラグまたはスティッキービット

制限付き削除フラグまたはスティッキービットは単一ビットであり、その解釈はファイルタイプによって異なります。ディレクトリの場合、
特権のないユーザーがファイルまたはディレクトリを所有していない限り、ディレクトリ内のファイルを削除したり名前を変更したりすることを防ぎます。これはディレクトリの制限付き削除フラグと呼ばれ、/ tmpのような誰でも書き込み可能なディレクトリによく見られます。一部の古いシステムの通常のファイルの場合、ビットはプログラムのテキストイメージをスワップデバイスに保存するため、実行時にロードが速くなります。これはスティッキービットと呼ばれます。

コメント

• 実際には、スティッキービットは以前に実行可能ファイルに適用されていたため、最初にロードされた後もスワップのままになりました。使用頻度の高いプログラムでは、不要なディスク/ネットワーク（NFS）とCPUの使用量が多くなります。ただし、Linuxもほとんど（すべて？）のUnixシステムもこれをサポートしなくなりました（カーネルから削除されました）。It' s " sticky "、実行可能ファイルがスワップでスタックしたため。さらに、ディレクトリに次のように使用されました。
• 実際には"よく使われているまたは非常に大きい"の方がわかりやすいでしょう。私の大学が持っていたことを思い出してください。 "スティッキー"」。非常に頻繁に使用された非常に小さなプログラム（例：システムコマンドはcronによって頻繁に実行され、大規模なプログラム（Netscapeなど）は"スティッキー"にするための主要な候補でした。どちらの場合も、ディスク/ NFSから常にリロードするのは無駄です。
• スティッキービットプログラムは、スワップではなくRAMに常駐することを目的としていました（スワップファイルからイメージをロードすることは'ファイルシステムディスクからロードするよりもはるかに高速です）。これは、lsのような重要なOSレベルのコマンドを対象としていました。明らかに、スーパーユーザーだけがファイルにスティッキービットを設定できました。仮想メモリと共有ライブラリが導入された後、特にページャーがよりスマートになり、どのページを常駐させるかを動的に決定できるようになったため、重要性は低くなりました。
• スティッキープロパティはディレクトリにとって意味がないため、同じです。パーミッションマスクのビットは、ディレクトリの従来のファイル作成セマンティクスを変更するために後で解釈されました。
• @alexis：元々、スティッキービットプログラムはスワップスペースに保持されていました。スワップファイルイメージの読み取りは連続したセクターであり、ほとんど非同期で読み取ることができるため、これはファイルシステムからの読み取りよりもはるかに高速でした。初期のファイルシステムでは、セクター"の実行長"はなく、ほとんどの初期のファイルシステムドライバーは、セクターが一度に1つのセクターを読み取ります。たまたま連続していた。 PDP-40での結果は、スティッキープログラムが即座にロードされるように見えたのに対し、非スティッキープログラムは通常の1〜2秒かかりました。 edスティッキーしかなかったと思います。

「プログラムの実行終了後にプログラムのイメージをメモリに保持するようにシステムにフラグを立てる実行可能プログラムに適用されるスティッキービット。」

これはかなり時代遅れの情報だと思います。今日、ほとんどの最近のUnixはそれを無視しています。Linuxでは、スティッキービットはディレクトリにのみ関係します。はこちらをご覧ください。 と非常に有益なウィキペディアの記事。

とにかく、その古い動作では、画像（「コード」のみであり、データ）は仮想メモリにのみ保持されました。次回はより高速に実行できるように、通常は実際のメモリではなくスワップされます。

スティッキービットとは何ですか？

スティッキービットは、設定される許可ビットです。 t内のファイルの所有者のみを許可するディレクトリファイルを削除または名前変更するhatディレクトリまたはrootユーザー。他のユーザーが作成したファイルを削除するために必要な権限を持っているユーザーは他にいません。

これは、重要なフォルダとそのコンテンツ（サブディレクトリとファイル）の削除を回避するためのセキュリティ対策です。完全な権限。

コメント

• その'は正しくありません： en.wikipedia.org/wiki/Sticky_bit
• @ABあなたが引用しているウィキペディアの記事の冒頭を言い換えるところまで、私にはかなり正確に思えます。 'の何が問題になっていますか？
• 答えは不完全だと思います。 " Sticky "は、実行可能ファイルをより高速に実行するためにスワップスペースに保持されることも示します。さて、これは古代の歴史ですが、古いファイルシステムでは、セクターがたまたま連続していても、ドライバーは一度に1つのセクターを読み取るために使用されていました。これにより、非スティッキー実行可能ファイルが遅くなり、スティッキーは当時非常に理にかなっています。