This is so wierd. Logged in to a Linux (RHEL) box as a user 'g', doing an ls -lah
shows
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
So the user 'g' in group 'g' /should/ be able to read and write to the .ssh directory but if I do ls -lah .ssh/
I get ls: .ssh/: Permission denied
. I also get Permission denied if I try and cat
any files in the directory
If I go in as root and change the permissions to 700
, 744
, 766
or anything as long as the 'user' permission is 7 it works and I can CD and LS the directory and files within.
id g
returns
uid=504(g) gid=506(g) groups=506(g)
Edit:
I've copied these permissions exactly to another identical box and there is no issue. I can cd
into a directory without execute permissions.
The directory will require the execute bit set in order for you to enter it. I don't know what you tested, but you cannot enter a directory without the execute bit, or read files in it:
That is, unless your process has the CAP_DAC_OVERRIDE POSIX capability set (like root has), which allows you to enter directories without the executable bit set, iirc.
Basically, you should try to keep you .ssh directory at 700, and everything in it at 600, just to be safe. The ssh man page gives per file instructions on the required ownerships and permission modes for files in ~/.ssh.
A directory requires execute permission in order to
cd
into it. This is the behavior that is expected.In order to ls or cd into a directory, you need execute permissions. While you don't have them, you can not really inspect the content and see the permissions of the files inside, so most probably the file permissions are wrong themselves, if you can not cat them.
Directory permission of 700 and file permissions 644 are perfectly OK setup for me.
I take it this is a an ssh file issue now ? not a general chmod issue ?
If so try
Directories need x bit set (for directory that bit is seen as search bit) to open. So I use tree so I can get only the folder set and avoid the nightmare of having all the files set as executables ( the option for tree is
-d List directories only.
):Warning!!! you should have this into considerations:
using chmod or chown recursive on root
/
directory or system directories will destroy your OS (actually anything recursive on/
directory or system directories is dangerous)this is not a good security practice to set permission bulk like that