For a user process, I want to mount a directory in other location but in user space without root privilieges. Something like mount –bind /origin /dest, but with a vfs wrapper. Like a usermode fine-tuned chroot.
The program would wrapper the syscalls to files to “substitute” the paths needed. It could be called with a command line like:
bindvfs /fake-home:/home ls /home
I am sure that this alredy exists! 🙂
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
You can use PRoot almost the same way as in your example:
proot -b /fake-home:/home ls /home
Unlike BindFS/FUSE, PRoot is able to bind over files and directories you don’t own.
Method 2
The parrot program can
do what you ask for: intercept system calls and redirect certain
paths (e.g., all paths starting with /anonftp are remapped to
transparently access remote files over FTP). It also runs entirely in
userspace.
However, despite an impressive array of common and uncommon network
protocols, parrot does not have any module to do simple
filesystem->filesystem rewriting like you ask for. That should be
quite simple to add, if you know some C language programming.
Alternatively, bindfs (which
runs on top of FUSE), works like a
mount --bind in userspace. (But this goes in the reverse direction
relative to re-directing /home to /fake-home as you mention in your question.)
Method 3
VFS already allows for non-root mounting of filesystems. You can add the user or users option to the fstab entry and make sure vfs.usermount=1 is in /etc/sysctl.
None of this will give you chroot-like controls however. The bind option isn’t going to change permissions or allow for an ‘alternate’ access, this is a second mtab entry for the same exact filesystem and contents. Modifications in the bind mount affect the original.
I’d make sure you clarify your end goal before moving further.
Method 4
mount_namespaces will allow you to do mount --bind not seen by other processes. But normally mount --bind is restricted to the root user only (for security reasons). So, for mount_namespaces to be of some use to a non-root user, you should first use user_namespaces to become a “local root” in a new namespace, where this operation would be allowed then.
You can play with this in your shell like this — this examples specifically shows the use of user&mount spaces in preparation of a chroot directory (and the chroot operation is normally privileged, too):
unshare --user --map-root-user --mount-proc --pid --fork mkdir -p newroot/dev mount --rbind /dev newroot/dev ....other chroot preparation.... chroot newroot su - user1
Note, that I’m using mount --rbind (instead of mount --bind), because only this will work in the new user&mount namespace, if the directory includes other mount points (and /dev/ does in my case).
Perhaps the explanation for this is that the user should not get a way to see something what normally an unprivileged user wouldn’t see, i.e., the subdirectories hidden by the “submounts”. Not to strip the submounts, only --rbind is allowed.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0