Classic Confinement Request for chapeey

store-requests classic-confinement
1

name: chapeey

description: A CLI tool for configuring and switching between

secure network tunnel environments on Linux servers.

snapcraft: PRIVATE

upstream: PRIVATE

upstream-relation: I am the author and sole developer of chapeey.

supported-category: tools for local, non-root user driven

configuration of/switching to development workspaces/environments

reasoning: chapeey needs to work directly with the host’s network

stack — specifically tun/tap interfaces and kernel routing tables —

to set up and manage tunnel environments. I tried making it work

under strict confinement but the required network-level interactions

happen outside the snap sandbox and the available interfaces don’t

cover this use case. The tool simply can’t do its job without

operating at the host network level.

Snap Store link: https://snapcraft.io/chapeey

:white_check_mark: I understand that strict confinement is generally preferred over classic.

:white_check_mark: I’ve tried the existing interfaces to make the snap work under strict confinement.

2

This request has been added to the queue for review by the @reviewers team.

3

Your app does not seem to be a tool to prepare build environments or some such but rather a network setup/management tool which this category does not cover…

This is what the network-setup-control, firewall-control and/or network-manager interfaces are for, note that even with a classic snap you would have to bundle many of your userspace tools in the snap (i.e. the nftables/iptables/xtables binaries and such) since your snap will have to be able to be installable (and runnable) on any linux that can use snaps (fedora, suse, archlinux, yocto, gentoo, debian etc etc) even classic snaps can/should not rely on any executables being available on the host. The interfaces will allow your snap to access all required parts of the kernel as well as systemd-networkd, -resolved and/or even network-manager if desired.

4

Hi ogra,

Thanks for the clarification — that makes sense on the category, I agree this fits better as a network setup/management tool rather than a development environment tool.

On the confinement side, I did try using network-setup-control, firewall-control and network-manager with bundled tools (iproute2, iptables/nftables, OpenVPN), but I’m still seeing issues where:

routing changes (ip route, ip rule) don’t consistently apply at the host level

TUN/TAP interfaces aren’t reliably usable across multiple components

coordinating services (OpenVPN, HAProxy, Dropbear) breaks in some cases

Since the tool needs to manage interfaces and routing in a system-wide way, the behavior under strict confinement differs from running directly on the host.

Just to check — is this kind of system-wide routing + interface control expected to work fully under these interfaces, or would that fall outside what strict confinement is designed for?

Happy to share logs or a minimal repro if needed.

Thanks

5

I would expect so, given we have plenty strictly confined VPN clients in the store that will likely have to do the same kind of network adjustments, perhaps it would make sense to take look at their packaging how they achieve this…