Request for classic confinement: parsec

[touilleMan]

Hi there,

I want to package parsec with a snap. Parsec aims at provide dropbox-like cloud data store and sharing on top of an encryption layer.
The reason I want classic confinement for this application is it uses FUSE to mount a virtual filesystem to expose user data.
I saw snap provide the fuse-support interface, but it only allow root to do the mount which is a no go for a user application.

Source code repos are located there:

• https://github.com/scille/parsec-cloud
• https://github.com/scille/parsec-gui

Thanks

[jdstrand]

How does your snap behave on systems where fusermount is not setuid?

[touilleMan]

Hi,

My understanding of fuse is that fusermount is required to be setuid, so without setuid I guess the application won’t be able to mount the virtual filesytem and will log the error and crash. This behavior should happened the same way no matter if the application is packaged as a snap classic or installed in a more traditional way.

[jdstrand]

Well, some systems may limit the group membership, etc or not have the binary installed at all (eg, Ubuntu Core systems). Of course your request for classic means that the snap wouldn’t be available on classic either.

A detailed write-up is given here: https://github.com/snapcore/snapd/pull/1598#issuecomment-239952977.

I would like to better understand this comment: “The reason I want classic confinement for this application is it uses FUSE to mount a virtual filesystem to expose user data.”. Can you give precise details on how the mounts work (eg, mountpoints, mount options, etc)?

[touilleMan]

Thanks a lot for the link on github issue comment, this gives me more understanding of the fuse interface

Can you give precise details on how the mounts work (eg, mountpoints, mount options, etc)?

Here is how works the application:

1. user starts the application
2. application display a login page
3. user logs in
4. application loads the user’s configuration including the path where fuse should be mounted (let’s say $HOME/parsec-mnt for instance). It’s totally acceptable to force the user to only mount in his home or in the /media/<username>/ folder.
5. application starts fuse (application is in python and I use the fusepy library as a slim wrapper on libfuse), this exposes the user’s data. Using mount -l I got:

FuseOperations on /home/touilleMan/parsec-mnt type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

6. user can decide to logout (to login as another identity for instance). This cause the application to stop the fuse and unmount the fuse mountpoint

From what I understood, snap fuse interface:

• is not connected automatically, meaning user should do an additional manual operation once the snap installed to enable this. I guess the manual phase has to be done only once (and not each time the application is started or each time snapd is restarted). This still leave me puzzled with the Can mount fuse filesystems (as root only). documentation sentence about the fuse-support interface. Does this means once the interface connected, the application must be run as root (typically by having snapd prompt a root password box before actually running it) ?
• doesn’t support unmounting (even if the mountpoint has been mounted by the same process like in my usecase). This is not compatible with the logout phase of my application. BTW, this is still a bit strange for me given I would say not unmounting your fuse before closing an application can leave a zombie mountpoint (i.e. ls on the path ends up with a Transport endpoint is not connected error), I got the case when using SIGKILL on my application. Is there something I’m missing there ?
• you wrote in the github issue Furthermore, the snap-confine command creates a new mount namespace so the fuse mounts aren’t accessible to other processes outside of the app’s process. Does this means the fuse mountpoint wouldn’t be accessible from 3rd party applications (for instance opening a text file with vi or reading a movie with vlc ?). If so this would make fuse pretty useless so I guess I read this wrong

Of course your request for classic means that the snap wouldn’t be available on classic either.

I’m not sure what you mean by that…

[jdstrand]

@touilleMan

From what I understood, snap fuse interface:

• is not connected automatically, meaning user should do an additional manual operation once the snap installed to enable this. I guess the manual phase has to be done only once (and not each time the application is started or each time snapd is restarted).

Yes. There is a process for requesting auto-connection as well: Process for aliases, auto-connections and tracks

@touilleMan

This still leave me puzzled with the Can mount fuse filesystems (as root only). documentation sentence about the fuse-support interface. Does this means once the interface connected, the application must be run as root (typically by having snapd prompt a root password box before actually running it) ?

Yes, this is precisely what it means. The aforementioned PR comment discusses that the fuse-support interface has a number of limitations. You would need a new interface called ‘fuse-control’ and for the core snap to ship fusermount for your snap to work in strict mode as non-root, but see below for a complication.

@touilleMan

• doesn’t support unmounting (even if the mountpoint has been mounted by the same process like in my usecase). This is not compatible with the logout phase of my application. BTW, this is still a bit strange for me given I would say not unmounting your fuse before closing an application can leave a zombie mountpoint (i.e. ls on the path ends up with a Transport endpoint is not connected error), I got the case when using SIGKILL on my application. Is there something I’m missing there ?

You aren’t missing anything. The fuse-support interface is limited (see above). Unmount would be supported by a fuse-control interface.

@touilleMan

• you wrote in the github issue Furthermore, the snap-confine command creates a new mount namespace so the fuse mounts aren’t accessible to other processes outside of the app’s process . Does this means the fuse mountpoint wouldn’t be accessible from 3rd party applications (for instance opening a text file with vi or reading a movie with vlc ?). If so this would make fuse pretty useless so I guess I read this wrong

The fuse-support interface is there to support other scenarios different from allowing a snap to make fuse mounts available to the global mount namespace of the host.

@touilleMan

Of course your request for classic means that the snap wouldn’t be available on classic either.

I’m not sure what you mean by that…

Well, yes, I had a typo I meant to say "Of course your request for classic means that the snap wouldn’t be available on non-classic distro (ie, Ubuntu Core) either.

[jdstrand]

The requirements for classic confinement are understood:

• fuse-support requires root, doesn’t allow unmounting and doesn’t allow use of fusermount (a new fuse-control interface would need to be created to allow this)
• fusermount does not exist in the core snap and app snaps aren’t allowed to ship setuid executables, so a devmode/strict snap isn’t going to have a usable fusermount
• since snaps run in their own mount namespace, there are potential complications exposing a fuse mount from a snap to the global mount namespace

@evan, @Wimpress, @popey - can one of you vet the publisher and otherwise comment on its suitability for classic confinement?

[Wimpress]

@jdstrand I can confirm that @touilleMan is Emmanuel Leblond a core upstream parsec contributor, in particular, parsec-cloud.

I’m +1 on granting classic as the reasons for the requirement are clear.

[popey]

+1 from me as a classic snap too.

[jdstrand]

Thanks @Wimpress

Granting use of classic. This is now live.

[jdstrand]

FYI, you’ll either want to upload a new revision or request a manual review for the existing revision and it will pass review.

[touilleMan]

Thanks you all very much

I’ll be uploading a new version of the package soon.