permission errors when using files outside $HOME

[warner]

Howdy.. thanks for packaging magic-wormhole!

We noticed some surprising permission errors when wormhole is run on files outside the user's $HOME directory, that only happen with the snap-packaged version. I've read a little bit about the "connections" model (which is pretty cool), and I think I now understand where those errors are coming from. I'm wondering if I have the limitations correct, and then whether we should try to do something about them, or maybe find a way to document/explain them to the user.

As I understand it, the snap-packaged version of wormhole can only send/receive files in the running user's $HOME directory, so wormhole send /etc/fstab or ~otheruser/publicfile.txt won't work, even as root. And wormhole send ~/.bashrc won't work because dotfiles are prohibited if they're directly under $HOME. And wormhole send /tmp/foo.txt won't work because wormhole uses a private /tmp that is not shared with user (although it is shared with other invocations of wormhole, including those by other users, which could be pretty surprising and kinda a security concern). Does that seem right?

Users could work around the confinement limitations by e.g. copying the file into their home directory before wormhole sending the copy, but it's a nuisance and the source of the error is pretty hard to discover.

I'm wondering if it would be appropriate for us to use the personal-files and/or system-files interfaces to grant full filesystem access to the wormhole program. I'd want to make sure this didn't grant e.g. /etc/shadow access to non-root users: the AppArmor restrictions are in addition to the normal unix account permissions, right?

Or maybe switch to confinement: classic? (that might be overpowered, wormhole certainly doesn't need anything beyond network and filesystem permissions).

Another option is to have wormhole somehow try to discover that it's running in this form of confinement, and print better error messages when that confinement is triggered. I don't think I'd want it to compare e.g. argv[0] == '/snap/bin/wormhole', that feels a bit fragile/self-important, but it's probably a better option than reading/writing a bunch of temporary files in various places to look for errors as a way to detect that we're confined.

The big problem right now is that the failure is pretty opaque. cat works just fine on all those filenames, but somehow wormhole send pretends as if they're unreadable. The difference between ~/.bashrc and ~/foo/.bashrc is especially funky. I don't have a lot of experience with AppArmor, I suppose some users may be unsurprised that snap-packaged tools are restricted, but we had a number of people chime in on the bug, thinking it was a problem in wormhole or its packaging.

Any recommendations on what we should do?

thanks,
-Brian

[brlin-tw]

Hello, just a random user/packager passing by, also thanks a bunch for the lovely application!

Does that seem right?

Yes, your speculations are pretty much accurate, note that it is also possible to access files under /mnt and /media after the connection of the removable-media interface, which should cover some more non-technical use cases.

I'm wondering if it would be appropriate for us to use the personal-files and/or system-files interfaces to grant full filesystem access to the wormhole program.

It won't be appropriate as the major use-case of these interfaces is to access application-specific files, not generic files in the system directories.

the AppArmor restrictions are in addition to the normal unix account permissions, right?

Correct.

switch to confinement: classic?

It might be possible to provide both versions of the same snap, search nano, classic on the Snapcraft Forum for an attempt.

Any recommendations on what we should do?

I agree the current packaging causes many frustrations, I believe that implementing snap confinement command-line argument checks and warning/workaround messages in the snap launcher/wrapper scripts might be a way to properly mitigate the problems.

Cheers!