It's a bug: https://tracker.ceph.com/issues/50060 On Wed, Dec 23, 2020 at 5:53 PM Alex Taylor <alexu4993@xxxxxxxxx> wrote: > > Hi Patrick, > > Any updates? Looking forward to your reply :D > > > On Thu, Dec 17, 2020 at 11:39 AM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote: > > > > On Wed, Dec 16, 2020 at 5:46 PM Alex Taylor <alexu4993@xxxxxxxxx> wrote: > > > > > > Hi Cephers, > > > > > > I'm using VSCode remote development with a docker server. It worked OK > > > but fails to start the debugger after /root mounted by ceph-fuse. The > > > log shows that the binary passes access X_OK check but cannot be > > > actually executed. see: > > > > > > ``` > > > strace_log: access("/root/.vscode-server/extensions/ms-vscode.cpptools-1.1.3/debugAdapters/OpenDebugAD7", > > > X_OK) = 0 > > > > > > root@develop:~# ls -alh > > > .vscode-server/extensions/ms-vscode.cpptools-1.1.3/debugAdapters/OpenDebugAD7 > > > -rw-r--r-- 1 root root 978 Dec 10 13:06 > > > .vscode-server/extensions/ms-vscode.cpptools-1.1.3/debugAdapters/OpenDebugAD7 > > > ``` > > > > > > I also test the access syscall on ext4, xfs and even cephfs kernel > > > client, all of them return -EACCES, which is expected (the extension > > > will then explicitly call chmod +x). > > > > > > After some digging in the code, I found it is probably caused by > > > https://github.com/ceph/ceph/blob/master/src/client/Client.cc#L5549-L5550. > > > So here come two questions: > > > 1. Is this a bug or is there any concern I missed? > > > > I tried reproducing it with the master branch and could not. It might > > be due to an older fuse/ceph. I suggest you upgrade! > > > > I tried the master(332a188d9b3c4eb5c5ad2720b7299913c5a772ee) as well > and the issue still exists. My test program is: > ``` > #include <stdio.h> > #include <unistd.h> > > int main() { > int r; > const char path[] = "test"; > > r = access(path, F_OK); > printf("file exists: %d\n", r); > > r = access(path, X_OK); > printf("file executable: %d\n", r); > > return 0; > } > ``` > And the test result: > ``` > # local filesystem: ext4 > root@f626800a6e85:~# ls -l test > -rw-r--r-- 1 root root 6 Dec 19 06:13 test > root@f626800a6e85:~# ./a.out > file exists: 0 > file executable: -1 > > root@f626800a6e85:~# findmnt -t fuse.ceph-fuse > TARGET SOURCE FSTYPE OPTIONS > /root/mnt ceph-fuse fuse.ceph-fuse > rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other > root@f626800a6e85:~# cd mnt > > # ceph-fuse > root@f626800a6e85:~/mnt# ls -l test > -rw-r--r-- 1 root root 6 Dec 19 06:10 test > root@f626800a6e85:~/mnt# ./a.out > file exists: 0 > file executable: 0 > root@f626800a6e85:~/mnt# ./test > bash: ./test: Permission denied > ``` > Again, ceph-fuse says file `test` is executable but in fact it can't > be executed. > The kernel version I'm testing on is: > ``` > root@f626800a6e85:~/mnt# uname -ar > Linux f626800a6e85 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) > x86_64 GNU/Linux > ``` > > Please try the program above and make sure you're running it as root > user, thank you. And if the reproduction still fails, please let me > know the kernel version. > > > > 2. It works again with fuse_default_permissions=true, any drawbacks if > > > this option is set? > > > > Correctness (ironically, for you) and performance. > > > > -- > > Patrick Donnelly, Ph.D. > > He / Him / His > > Principal Software Engineer > > Red Hat Sunnyvale, CA > > GPG: 19F28A586F808C2402351B93C3301A3E258DD79D > > > -- Patrick Donnelly, Ph.D. He / Him / His Principal Software Engineer Red Hat Sunnyvale, CA GPG: 19F28A586F808C2402351B93C3301A3E258DD79D _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |