これはとても奇妙です。 Linux(RHEL)ボックスにユーザー 'g'としてログインし、ls -lah
を実行します
drwxrwxrwx 6 g g 4.0K Jun 23 13:27 .
drwxrw-r-x 6 root root 4.0K Jun 23 13:15 ..
-rwxrw---- 1 g g 678 Jun 23 13:26 .bash_history
-rwxrw---- 1 g g 33 Jun 23 13:15 .bash_logout
-rwxrw---- 1 g g 176 Jun 23 13:15 .bash_profile
-rwxrw---- 1 g g 124 Jun 23 13:15 .bashrc
drw-r----- 2 g g 4.0K Jun 23 13:25 .ssh
したがって、グループ 'g'のユーザー 'g'は.sshディレクトリの読み取りと書き込みができるはずですが、そうするとls -lah .ssh/
を取得するとls: .ssh/: Permission denied
になります。また、ディレクトリ内のファイルをcat
しようとすると、アクセスが拒否されます
Rootとしてアクセスし、権限を700
、744
、766
など、「ユーザー」権限が7である限り、機能し、ディレクトリをCDおよびLSに変更できる場合内のファイル。
id g
が返されます
uid=504(g) gid=506(g) groups=506(g)
これらの権限を別の同じボックスに正確にコピーしましたが、問題はありません。実行権限なしでディレクトリにcd
できます。
ディレクトリwillを入力するには、実行ビットを設定する必要があります。私はあなたが何をテストしたかわかりませんが、あなたはできません実行ビットなしでディレクトリに入るか、その中のファイルを読み取ります:
$ mkdir foo
$ echo "baz" > foo/bar
$ chmod 660 foo
$ cd foo
bash: cd: foo: Permission denied
$ cat foo/bar
cat: foo/bar: Permission denied
つまり、nlessプロセスにCAP_DAC_OVERRIDE POSIX機能セット(rootのように)があり、実行ビットセットiircなしでディレクトリに入ることができます。
基本的に、安全のために、.sshディレクトリを700に、その中のすべてを600に保つようにしてください。 sshのmanページでは、ファイルごとに〜/ .ssh内のファイルに必要な所有権とアクセス許可モードについて説明しています。
ディレクトリにcd
するには、実行権限が必要です。これは予想される動作です。
ディレクトリにlsまたはcdするには、実行権限が必要です。あなたはそれらを持っていませんが、コンテンツを実際に検査して内部のファイルの権限を確認することはできません。したがって、それらを分類できない場合、おそらくファイル権限自体が間違っています。
700のディレクトリ許可と644ファイル許可は、私にとってはまったく問題のない設定です。
これはsshファイルの問題だと思いますか?一般的なchmodの問題ではありませんか?
もしそうなら
$chmod go-w ~/
$chmod 700 ~/.ssh
$chmod 600 ~/.ssh/*
$chmod 600 ~/.ssh/.*
ディレクトリを開くには、xビットセット(そのビットが検索ビットと見なされるディレクトリ)が必要です。したがって、私はツリーを使用して、フォルダーセットのみを取得し、すべてのファイルを実行可能ファイルとして設定するという悪夢を回避できます(ツリーのオプションは-d List directories only.
):
Sudo tree -faid here_goes_your_directory xargs -L1 -I{} Sudo chmod 755 "{}"
警告!!!これを考慮に入れる必要があります。
ルートでchmodまたはchownを再帰的に使用する/
ディレクトリまたはシステムディレクトリはOSを破壊します(実際には/
ディレクトリまたはシステムディレクトリは危険です)
これは、そのような権限の一括を設定するための良いセキュリティ慣行ではありません