Fuse options not working

[maflister]

Version of Singularity What version of Singularity are you using? 3.8.3

Describe the bug When using the --fusemount option, if the fuse command includes the allow_other flag, it is not passed to singularity during the mount process.

To Reproduce

$singularity shell --fusemount "host:gocryptfs -allow_other --extpass echo --extpass testing /home/test/encrypted /home/test/decrypted" /path/to/container.sif
$mount
 fuse on /home/test/decrypted type fuse (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)

Expected behavior We expect that allow_other flag will result in fuse mount with allow_other and default_permissions.

$singularity shell --fusemount "host:gocryptfs -allow_other --extpass echo --extpass testing /home/test/encrypted /home/test/decrypted" /path/to/container.sif
$mount
 fuse on /home/test/decrypted type fuse (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001,allow_other,default_permissions)

OS / Linux Distribution Which Linux distribution are you using?

CentOS Linux release 7.9.2009 (Core)

Installation Method source

Additional context I found that if I modify https://github.com/sylabs/singularity/blob/8583de5effeb4eb0868b0e597203f66b4e1f6343/internal/pkg/runtime/engine/singularity/container_linux.go#L447 and https://github.com/sylabs/singularity/blob/8583de5effeb4eb0868b0e597203f66b4e1f6343/internal/pkg/runtime/engine/singularity/container_linux.go#L2451 so that they both include ",default_permission,allow_other", then everything works as I expect. So, I am wondering if the code can be modified to honor any fuse options that are added inline.

[dtrudg]

Hi @maflister - could you give a bit more background information about what you need to accomplish here?

When singularity is run without --fakeroot you cannot become another user in the container. Therefore, I'd not really expect the allow_other flag to be useful. We set it when --fakeroot is in play because you can then become a different user in the container.

[maflister]

For sure. That's just my crude workaround for the current situation. Other than it being a workaround, it's unrelated to the actual issue which is that when I pass an option to the fuse command, it does not seem to modify the resulting fusemount in the container.

Thanks.

[maflister]

Hopefully this is a better example from the documentation. There is no difference between the following:

singularity run --fusemount "host:sshfs server:/ /server" docker://ubuntu

singularity run --fusemount "host:sshfs -o allow_other server:/ /server" docker://ubuntu

I would expect that if I give sshfs an option, it should be read by Singularity and modify the resulting fusemount. However, these commands are identical and the resulting mounts are identical.

[dtrudg]

Right - this isn't trivial to do, unfortunately. Because the FUSE binary is running on the host here, but we want the mount to take place in the container, the sshfs call isn't performing the mount itself so the mount options don't apply.

The singularity engine has to open a /dev/fuse file descriptor, and pre-mount it inside the container... then call the fuse program (such as sshfs) instructing it to operate on that file descriptor, to populate the pre-mounted fs.

Because the call to the FUSE program (such as sshfs) isn't directly performing the mount, the mount options aren't set as they would be if you run the command standalone.

We can't always really read the options out of the provided command line. An -o xxxx, where xxx is an option documented in man mount.fuse is pretty standard, but your gocryptfs example uses -allow_other instead.

I'm still somewhat confused in what circumstance you need allow_other but you aren't using --fakeroot? What's a specific workflow that specifying allow_other or another mount.fuse option would permit? As mentioned before, I wouldn't expect the permissions / allow_other options to be meaningful outside of --fakeroot mode, as you cannot change uid inside the container.

[maflister]

Thanks for explaining the complexity. Our use case is to mount an encrypted file space into a container which runs a desktop. We also want to be able to have shared encrypted file spaces for projects, which is where we need allow_other. Basically we want to use the encryption from gocryptfs, functionality of mounting on the fly in a container, and have it rely on the native group file permissions. Hopefully that makes sense.

This is probably a convoluted/rare use case and I'd be open to other suggestions. However, if there is a way to specify a fuse option, that would be great.