Making a virtual file system available to gvisor

[Raj Wilkhu]

Hi,

I have been trying to implement and provide my own gofer binary that allows mounting of a file system (from the host) per sandbox. The host maps then file system to a storage backend via FUSE.

I have had to provide my own runsc using a "--gofer-binary" option to provide my own gofer-side filesystem backend.

I can't stop thinking that there must be an easier way to dynamically mount a path to a mounted file system on the host. Any help here would be greatly appreciated.  

Raj

[Ayush Ranjan]

I don't think there is any flag like "--gofer-binary".

If you have a host FUSE mount, you can expose that into the sandbox as a normal directory and it should work. Alternatively, you can see the work done in https://github.com/google/gvisor/pull/13216 to see how you can implement a custom LISAFS connection.

[Raj Wilkhu]

Ayush mate, thanks very much for the quick response and pointer to the PR.

Been banging my head for a week - I had forked gvisor and was playing around with my own runsc which didn't seem right. Wish I had asked you sooner.

Thanks again,

Raj

[Etienne Perot]

By the way, one idea we've been floating around is the possibility of creating a "FUSE adapter gofer" that can wrap an existing FUSE binary and automatically bridge it to a gVisor sandbox (essentially translating FUSE to LISAFS), without the host kernel roundtrip of FUSE. Could be done either by LD_PRELOAD or maybe by ptracing the FUSE process.

Either way, sounds like it would help here. More generally, it would allow unprivileged use of any filesystem type that there exists a FUSE implementation for (e.g. ext4, NFS, SMB, etc), and would work wherever gVisor does, even on hosts without /dev/fuse.

If that sounds like something you'd be interested in implementing, let the folks on this thread know :)

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gvisor-users/478b1ed6-e3f3-4c74-a0c9-2044a160f205n%40googlegroups.com.

[Shayon Mukherjee]

Hi team,

Thanks for the tag. Yeah, we’ve been running a custom filesystem on top of gVisor and LisaFS for our own storage path, and I should be able to share more about that soon.

In the meantime, I’d be happy to help pair, brainstorm, or put together a small experimental FUSE-adapter gofer example. Thinking about this as"a proof of shape" rather than a fully supported generic FUSE layer but very much open to feedback and ideas here too. 

The goal would be to give people enough working code to see how the fsgofer extension path can host a non-standard filesystem, then others can pick it up and push it further if it proves useful.

Given the work Ayush already tagged in #13216, #13223 and few other older PRs, and taking from Etienne’s idea around a small LD_PRELOAD/libfuse-shim example would be the most useful first step. 

Something that runs a tiny libfuse “hello filesystem” style binary, intercepts the libfuse entry points, and translates a small read-only operation set into a LisaFS connection served by the gofer.

Perhaps an example directory along these lines:

  runsc/fsgofer/extension/examples/fuseadapter/

    BUILD

    README.md

    adapter.go

    fuse.go

    libfuse_shim.c

    hello_fuse.c

    adapter_test.go

Or `runsc/fsgofer/examples/fuseadapter/` if that fits the tree better.

We can even do support overtime for operations like writes, rename, unlink, xattrs,, fd donation even? The README can be clear about those limits and explain that this avoids /dev/fuse and host FUSE mounts.

Curious what others think. I can look into get something going in a draft PR in the next 1-2 weeks too. 

Thanks,

Shayon