"スティッキービット"はディレクトリのみですか？私はそれがファイル上にあるかもしれない、奇妙なことがわかった

Question

ウェブサイトからのサンプルは、 "スティッキービット"はディレクトリ用です。

$ ll /tmp 
drwxrwxrwt 16 root root 4096 1月 2 15:45 ./ 

私たちは、/ tmpは「T」での実行許可を見ることができ、誰もが実行することができますが、特定のディレクトリにのみ「ルート」や、その所有者のいずれかによって操作することができます。

これまでの私の理解では、このファイル許可フラグはディレクトリのみであり、ファイルではありません。私は、ファイルを作成するには、「開く」機能を使用していたとき、私のプログラムだったのでしかし、私は、私は3番目のパラメータとして任意のファイルのパーミッションを指定していない、この問題に遭遇した：実行後

#include<fcntl.h> 
#include<unistd.h> 
int main() 
{ 
    int f1=open("./mytest_c1.txt",O_CREAT|O_RDWR); 
    write(f1,"abc xyz\n",8); 
    close(f1); 
    return 0; 
} 

、私が得ました

--wxr-x--T 1 x x  8 1月 2 11:38 mytest_c1.txt* 

奇妙なのは、大文字の「T」です。

1. どのようにこの「T」フラグを生成しましたか？私は何も指定しなかった。
2. 小文字の「t」との違いは何ですか？

   -rw---x--T 1 x x  0 1月 2 15:59 mytest_c2.txt* 
   

   今回は、これまでに奇妙な：

   #include<fcntl.h> 
   #include<unistd.h> 
   int main() 
   { 
       int f1=open("./mytest_c2.txt",O_CREAT|O_RDWR); 
       close(f1); 
       return 0; 
   } 
   

   実行した結果は、別のファイルを作成：

は、だから私は私の実験を続けて、私はなるよう、ステートメントを "書く" 削除しました-er。 mytest_c2.txtのファイルアクセス権はmytest_c1.txtとは異なります。

この違いはどこから生じますか？私は私のプログラムで何も指定しなかった！

Answer 1

これは正しくありません。

int f1=open("./mytest_c1.txt",O_CREAT|O_RDWR); 

この文invokes undefined behavior（UB）。 にO_CREATが含まれているフラグを使用する場合は、は（manpagesに記載）のファイルモードを指定する必要があります。あなたが見ているスティッキービットは、UBのために予期せぬ事態が発生した結果です。今

、興味深いいくつかの他のポイント：

我々は、/ tmpのの実行許可が「T」で見ることができ、誰もが実行することができますが、特定のディレクトリには、いずれか一方のみ「ルート」で操作することができますまたはその所有者。

これはではありません。は間違っています。ディレクトリにスティッキービットを持っている場合（例えば、/tmp通常はありませんが）、それは誰もがそのディレクトリにファイルを作成できることを意味するが、より正確には所有者のみ（およびroot、rootはほとんど何でも行うことができますので、 ）は、ファイルが作成されると、そのファイルを変更または除外できます。

次へ：

のウェブサイトからのサンプルは、「スティッキービット」は、例えば、ディレクトリのためであると言います

また、間違っていないが、少し誤解を招く。スティッキービットcan be applied to filesですが、Linuxは単純にそれらを無視します。

Answer 2

差分：スティッキービットを示し、tバージョン実行ビットが設定されており、T実行ビットが設定されていません。

理由：Linuxは親ディレクトリからアクセス権を継承します（ディレクトリにACLを設定した場合、そのディレクトリ内のファイルのみがACLを継承します）。サブディレクトリを作成した場合、ACLがrecurseに設定されます）この場合、そのスティッキービットのファイルがあるフォルダが設定されます。それで新しく作られたファイルがそれを継承しているのです。

私の場合、ACLは再帰に設定されています。 OPの場合も、 に設定されています。さもなければ、親のACLを継承しません。