「$ sudo chmod -R 664 . 」を実行すると、影響を受けるすべてのディレクトリへのアクセスが拒否されるのはなぜですか?

「$ sudo chmod -R 664 . 」を実行すると、影響を受けるすべてのディレクトリへのアクセスが拒否されるのはなぜですか?

すべてのファイルの権限が乱雑になっているプロジェクト フォルダーがあります。セキュリティに関連しない問題はすべて解決するので、すべてを 8 進数の権限 777 に設定するという悪い癖がありました。すると、FTP アップロード、テキスト エディターで作成されたファイルなどには独自の権限セットがあり、すべてが乱雑になります。私は自分自身をまとめ、権限を本来の用途どおりに使用することにしました。

私は、664 がすべてのファイルとフォルダーの適切なデフォルトだと考え、プライベート ファイルの他のユーザーの権限を削除し、実行可能ファイルに +x を追加するだけでよいと考えました。

2番目にプロジェクトフォルダを664に変更しましたが、次のようになりました:

$ sudo chmod -R 664 。  
$ ls  
ls: ディレクトリを開けません。: 権限が拒否されました  

私には意味がわかりません。私には読み取り/書き込み権限があり、プロジェクト フォルダーの所有者です。ls -l私のプロジェクト フォルダーの左端の部分は次のようになります。

-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 5 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 3 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 4 codemonkey codemonkey ...
drw-rw-r-- 5 codemonkey codemonkey ...

これはディレクトリの権限に関係していると思いますが、何?

答え1

実行ビットは、*nix ディレクトリをトラバースするために必要です。実行権限のないディレクトリには入ることができませんcd。これは、ディレクトリ コンテキストを必要とする多くのユーティリティに、わかりにくい方法で影響を及ぼします。次の点を考慮してください。

$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo

# You can read the contents of the directory, but ls still complains. 
$ ls foo
ls: cannot access foo/bar: Permission denied
bar

# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied

これらすべての理由は、stat() の動作方法にあります。以下から抜粋man 2 stat:

ファイル自体に対する権限は必要ありませんが、stat() および lstat() の場合、ファイルにつながるパス内のすべてのディレクトリに対する実行 (検索) 権限が必要です。

要するに、再帰はchmod期待どおりに動作することはほとんどなく、ディレクトリの読み取りおよび実行権限に大混乱をもたらし、あなたのような予期しない結果につながる可能性があります。最良の結果を得るには、ディレクトリ権限を常にファイル権限とは別に扱うようにしてください。

答え2

ディレクトリに対する実行権限が必要です。

考慮する

sudo find -type d -exec chmod +x {} +

更新: 明らかに奇妙な実行権限の使用について、私の説明をここに記します。

Unix (および Linux) は、ほとんどすべてをファイルとして扱います。これは、ディスクやその他のさまざまなデバイスにも適用されます。ディレクトリも含まれます。

従来の Unix ファイルシステムには、ファイルに適用される一連の権限があります。そのため、Unix の設計者は、通常のデータ ファイルではない「ファイル」に適用されたときに、各権限ビットが行う便利な処理を見つけなければなりませんでした。

ディレクトリについて考えてみましょう。最初は、読み取り権限を使用して、誰かがディレクトリにアクセスできるかどうかを決定するのが合理的に思えます。たとえば、ディレクトリ内のファイルとそのサイズ、日付スタンプなどのリストを生成する場合などです。

しかし、一般ユーザーが /usr/local/bin 内のプログラムを実行できるようにしたいが、/usr/local 内を探し回ってそこに何があるかを確認できないようにしたいとします。読み取り権限しかない場合は、これを防止することはできません。

したがって、本来は冗長な実行権限は、シェルがディレクトリを「トラバース」できるかどうかを制御するために使用されます。つまり、パスの一部としてサブディレクトリの詳細を検索して読み取るために必要なもの以外は検索しません。これにより、/usr/local/bin の内容を読み取るために必要な範囲でのみ、/usr/local ディレクトリにアクセスできます。

したがって、/usr/local で +x を実行すると、「/usr/local/bin/foo」を実行できます。ただし、/usr/local で +r を実行すると、所有者、各ファイルの権限、サイズなど、/usr/local 内のすべての情報を確認できます。

上記は漠然とした記憶と推測に基づいています。正確には真実ではないかもしれませんが、「実行」が「通過可能」を意味する理由について、合理的な考えを与えていると思います。

関連情報