Trippy (https://github.com/fujiapple852/trippy) read a configuration file and therefore requires the home interface. As the application must be run with elevated privileges (i.e. via sudo) due to the need for CAP_NET_RAW (which is granted via the existing auto-connected network-observe interface) then it requires home: read: all.
Therefore please approve auto-connect for trippy for the home interface with read: all.
After taking a look to the original post, the use of home: read: all looks like an ugly workaround for a different problem to me, unless there is any reason to limit the use of your application to users with sudo privileges.
It seems that what you really need is to set the required capabilities (probably just cap_net_raw) to your binary. Whilst snaps seems to work fine with capabilities, it will fail automatic review, as review-tools does not support xattr currently.
Of course, if we think that it should be the way to go, we could still manually approve the snap while update review-tools to properly support this use case. Any thoughts? @alexmurray
Trippy on linux only requires CAP_NET_RAW. I understand that, when run as a snap, this means that it needs both the (existing) network_observe plug and to have CAP_NET_RAW. This is for the reason @James-Carroll gave in the thread, i.e. āThe (lack of) interfaces remove permissions, but adding interfaces canāt grant themā.
The question therefore is how can a snap be given CAP_NET_RAW other than running it as sudo? My understand (backed up by my experiment here) is that the ātraditionalā ways of giving the executable CAP_NET_RAW do not work with snap.
If so, and therefore if sudo is required (which was the conclusion from the prior thread) then the solution of using home: read: all was deemed as being the best option. I fully agree it is an ugly workaround and in fact not even a complete workaround (i.e. doesnāt work for hidden files and directories).
Do you know of a method of giving trippy CAP_NET_RAW that will work with snap? If so Iād be keen to explore that option.
# Install required tools
sudo apt install squashfs-tools libcap2-bin
# Unpack the snap to squashfs-root folder
unsquashfs <trippy.snap>
# Set the capability to the unpacked binary
setcap 'cap_net_raw=ep' <path to your binary>
# Check capability was set properly
getcap <path to your binary>
# Repack the snap
mksquashfs squashfs-root trippy_setcap.snap
# Install newly created binary
snap install --dangerous trippy_setcap.snap
# check everything works as expected
If it works, you could probably set the capability at build time by overriding one snapcraft stage (probably prime) in snapcraft.yaml. However, as I said, this binary with xattr will fail automatic review and Iām not sure if it is something we can/want to support.
Hi @jslarraz nice idea, I gave your technique a try and it works; Trippy can be run as an unprivileged user (but now with CAP_NET_RAW) and is also able to read the local user (non-hidden) config file.
# no sudo and reads from trippy.toml in the current directory if it exists
fuji@trippy-dev:~$ trippy 1.1.1.1
Caveat: I had to manually connect both home and the network-* interfaces for this test, I guess because iām installing locally with --dangerous.
However, as I said, this binary with xattr will fail automatic review and Iām not sure if it is something we can/want to support
We at least now know it can work, so I guess the question is whether it is better to go with home: read: all or support the approach you have suggested. For me I prefer the latter as it allows users to run via snap without sudo.
Aside: note that Trippy 0.10.0 was release several days ago and so snap is now lagging behind on 0.9.0 until this is resolved.
Thanks for checking, Iām glad to see that this solution works! ^^
After discussion with @pedronis and @alexmurray it seems we prefer to use the home: read: all solution for now. Thus, +1 from me for granting Trippy auto-connection to home: read: all interface
Separate to getting approval to enable the auto-connect, I also need someone to approve build 2667 which shows as " Status: Manual review pending" and āhuman review required due to ādeny-connectionā constraint (interface attributes) declaration-snap-v2_plugs_connection (home, home)ā since this was the first build which introduced home: read: all.
Are you able to approve that now or does that need to wait for a 2nd approval as with the auto-connect?
I ask as iām keen to get that part approved so I can make Trippy 0.10.0 available to snap users (even if they donāt have auto-connect for home immediately, as they are no worse off than they are for 0.9.0 in that regard).
Maybe you can reject the revision that is currently waiting for review and upload a new revision for Trippy 0.10.0 without including the home: read: all interface (which should pass automatic review).
Once we get the votes needed to grant auto-connection for the home: read: all interface, you can upload a new revision including the home: read: all interface
The snapcraft builds are connected to the GH repo on the master branch which has now moved on beyond 0.10.0 and so not suitable for deployment until 0.11.0 is ready (~end of the quarter). As far as I know there is no way to connect snapcraft at a GH branch such that I can build from a 0.10.x patch, do let me know if you know of a way.
So sounds like we just have to wait, once the needed approvals are in I trust the existing 0.10.0 builds (which have home: read: all) ca be unblocked and I can promote them to stable.
