0
I noticed that I can cd into non-executable directories that are mounted with sshfs
.
First, I created directories with all eight possible modes:
$ pwd
/mnt/remote
$ for i in {0..7}; do mkdir test_$i; chmod $i$i$i test_$i; done
$ ll
total 32K
d--------- 2 <user> <user> 4,0K Okt 19 12:39 test_0
d--x--x--x 2 <user> <user> 4,0K Okt 19 12:39 test_1
d-w--w--w- 2 <user> <user> 4,0K Okt 19 12:39 test_2
d-wx-wx-wx 2 <user> <user> 4,0K Okt 19 12:39 test_3
dr--r--r-- 2 <user> <user> 4,0K Okt 19 12:39 test_4
dr-xr-xr-x 2 <user> <user> 4,0K Okt 19 12:39 test_5
drw-rw-rw- 2 <user> <user> 4,0K Okt 19 12:39 test_6
drwxrwxrwx 2 <user> <user> 4,0K Okt 19 12:39 test_7
Then, I simply checked whether I could cd
into each them.
$ for i in {0..7}; do cd test_$i; echo $?; cd /mnt/remote; done
0
0
0
0
0
0
0
0
So cd
succeeds even for the non-executable directories, which should be impossible.*
As per the suggestion in the comments, I also tried to list the directory after opening it:
$ for i in {0..7}; do cd test_$i && ls >/dev/null; echo $?; cd /mnt/remote; done
ls: reading directory .: Permission denied
2
ls: reading directory .: Permission denied
2
ls: reading directory .: Permission denied
2
ls: reading directory .: Permission denied
2
0
0
0
0
The interesting directories here are test_4
and test_6
as they have read permission, but no execute permission. However, ls
succeeds for both of them. It does fail for test_0
through test_3
, which are missing read permission.
Why does this happen?
*: To confirm this, I did the same experiment on my local machine:
$ for i in {0..7}; do cd test_$i; echo $?; cd ~/work/permission_tests; done
cd: permission denied: test_0
1
0
cd: permission denied: test_2
1
0
cd: permission denied: test_4
1
0
cd: permission denied: test_6
1
0
So it does give the expected results there.
Assuming that you didn't log into the remote as root, I'd guess that sshfs isn't checking the permissions until it actually has to do something IN the directory. Try adding an ls after the cd and see if that succeeds - I'm guessing it won't. – Michael Kohne – 2017-10-19T11:26:21.573
Yes, I log on as a regular user. I added that experiment to the question. TL:DR;
ls
doesn't care about execute permission, only about read. So behaviour is the same as when listing from outside the directory. – iFreilicht – 2017-10-19T11:38:26.640Technically you can ls... Being non-executable really prevents you from accessing the inodes of the files under it. So
ls /path/to/nonexec
will give you the names of the files, but nothing else, since it needs to access the files inodes for this, and it can't since the directory in non-exec.ls
andls .
don't work because using.
requires traversing the directory. – xenoid – 2017-10-19T11:49:56.9431@iFreilicht read and exec permissions on a directory are two different things. Non-read prevents you from listing the contents, while non-exec prevents you from using that directory in a path to access its children. With +x/-r you can use the children if you know their names. – xenoid – 2017-10-19T11:54:11.123
@xenoid Ah, so upon further investigation,
ls
does soft-fail. It doesn't list anything, even if there are files in the directory, but it will exit with code 0. Very interesting. – iFreilicht – 2017-10-19T11:54:25.577Indeed, the man page for sshfs says that the reads are async by default, so I'm thinking it doesn't actually do the read until it needs to, and so doesn't fail to 'ls'. – djsmiley2k TMW – 2017-10-19T15:37:49.873
-o async_read perform reads asynchronously (default) -o sync_read perform reads synchronously
– djsmiley2k TMW – 2017-10-19T15:37:57.3832In addition to what has been said,
sshfs
is a FUSE file system, and as such it inherently "belongs" to the user that started it, no matter what the file permissions say. There are options like-o allow_root
and-o allow_others
, but they have interesting gotchas, and other interesting things happen if root startssshfs
. So I'm not that surprised that permissions don't exactly do what you expect them to do, even though I can't pinpoint details and reasons. – dirkt – 2017-10-20T05:25:34.533