Why can I cd into non-executable directories mounted with sshfs?

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.

iFreilicht

Posted 2017-10-19T11:20:12.323

Reputation: 331

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.640

Technically 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 and ls . don't work because using . requires traversing the directory. – xenoid – 2017-10-19T11:49:56.943

1@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.577

Indeed, 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.383

2In 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 starts sshfs. 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

No answers