0

While trying to create a test environment using mount --bind I was surprised to find that it sometimes fails with permissions errors because root cannot access the source directory. This only appears to affect NFS file-systems.

Is there a way to mount --bind a directory which root cannot access? Perhaps by inode number directly?

Example

I have an NFS mount which the ordinary vagrant:vagrant user can access fully:

vagrant@ubuntu-xenial:/tmp$ find nfs_mount/ -ls
     4375      4 drwxr-xr-x   3 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/
   257090      4 drwxr-xr-x   3 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/source
   257091      4 drwx------   3 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/source/path
   257092      4 drwx------   3 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/source/path/is
   257093      4 drwx------   2 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/source/path/is/here

... but root:root cannot:

vagrant@ubuntu-xenial:/tmp$ sudo find nfs_mount/ -ls
     4375      4 drwxr-xr-x   3 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/
   257090      4 drwxr-xr-x   3 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/source
   257091      4 drwx------   3 vagrant  vagrant      4096 Mar 20 21:28 nfs_mount/source/path
find: ‘nfs_mount/source/path’: Permission denied

If I attempt to mount --bind it fails:

vagrant@ubuntu-xenial:/tmp$ mkdir /tmp/bindtarget

vagrant@ubuntu-xenial:/tmp$ sudo mount --bind /tmp/nfs_mount/source/path/is/here/ /tmp/bindtarget/
mount: mount /tmp/nfs_mount/source/path/is/here/ on /tmp/bindtarget failed: Permission denied

The NFS mount at /tmp/nfs_mount is provided by localhost:/srv, and if I go directly to the source file-system the directory permissions don't pose a problem:

vagrant@ubuntu-xenial:/tmp$ sudo mount --bind /srv/source/path/is/here/ /tmp/bindtarget/

vagrant@ubuntu-xenial:/tmp$ findmnt /tmp/bindtarget
TARGET          SOURCE                              FSTYPE OPTIONS
/tmp/bindtarget /dev/sda1[/srv/source/path/is/here] ext4   rw,relatime,data=ordered

NFS setup in case it matters:

vagrant@ubuntu-xenial:/tmp$ showmount -e localhost
Export list for localhost:
/srv *

vagrant@ubuntu-xenial:/tmp$ cat /etc/exports
/srv/       *(rw,sync,no_subtree_check)

 Environment

  • Ubuntu 16.04 (Xenial64)
  • Linux ubuntu-xenial 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
2

Please note that doing any mount in /tmp is hazardous, because some cleaning task might suddenly decide to do its work in /tmp and not care about mountpoints, thus wiping old files not actually belonging to /tmp. That said I'll use the /tmp examples from OP.


method 1:

If you're in full control of the NFS environment, just add the no_root_squash option to the export options: this will prevent the root user client to be mapped as nobody on the server and losing rights.


method2:

Else, here's a relatively simple solution, the one you're looking for, in the same vein as accessing a still-in-use deleted file: using /proc

For simplicity here, requires two terminals:

user terminal:

vagrant@ubuntu-xenial:/tmp$ cd /tmp/nfs_mount/source/path/is/here/
vagrant@ubuntu-xenial:/tmp/nfs_mount/source/path/is/here$ echo $$
12345

root terminal: root can get a reference to the wanted directory, still unreadable, but mountable:

# ls -l /proc/12345/cwd
lrwxrwxrwx. 1 vagrant vagrant 0 Mar 21 01:18 /proc/12345/cwd -> /tmp/nfs_mount/source/path/is/here
# ls -l /proc/12345/cwd/
ls: cannot open directory '/proc/12345/cwd/': Permission denied

# mount --bind /proc/12345/cwd /tmp/bindtarget
# ls /tmp/bindtarget
ls: cannot open directory '/tmp/bindtarget': Permission denied

That's it.

  • That's a beautiful work-around, thank you! (Also a very good point about using /tmp, I hadn't considered tmpwatch et al) – RobM Mar 21 '18 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.