7

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! :)

imz -- Ivan Zakharyaschev
  • 15,462
Keymon
  • 763

4 Answers4

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

Riccardo Murri
  • 16,468
2

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.

Cedric
  • 36
1

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.

nzwulfin
  • 797
  • Well imagine this situation: I have a precompiled program, that I can not recompile. This program access to a fixed path, like '~/.program-data' and I need to launch several instances of the program as user, without doing chroot. Of course I could create a chrooted environment and use fakechroot, but it is too complex. – Keymon Sep 10 '10 at 06:56
  • 1
    So in that instance you are trying to provide a shared location (like /var/program-data) for users to all access as ~/.program-data when running said program? Or are you trying to provide separate copies of ~/.program-data to each instance of a program run by the same user? – nzwulfin Sep 15 '10 at 15:35
  • Both situations are ok. If can be by process instance, better. – Keymon Sep 30 '11 at 14:37
0

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.

Community
  • 1
imz -- Ivan Zakharyaschev
  • 15,462