Request auto-connect (home interface) for Trippy

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.

cc @mborzecki1 @ogra

Recent thread with background on why home: read: all is needed:

Previous thread on existing auto-connect permissions:

Current build which is awaiting manual review: https://dashboard.snapcraft.io/snaps/trippy/revisions/2667/

Hi @fujiapple852

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

@jslarraz thanks for the reply.

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.

Thanks.

I think you can do a quick check as follows:

# 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.

Any opinion or concern about this topic? @pedronis

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.

Hi @fujiapple852

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

Thanks

1 Like

Many thanks @jslarraz.

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.