[ryanjkirk]

Setting this up makes much less sense than setting up a tested vpn, such as wireguard or open, or even a persistent ssh tunnel using autossh to your home rpi.

I would never allow my prod systems to be potentially exposed by an api that runs as root. (And the documentation is incorrect on that; it should run as an unprivileged user with sudo privs to only run a wrapper script that runs firewall-cmd).

This also makes little sense in the context of configuration management, which should be enforcing a static set of iptables rules.

[stqism]

Personally I’d make a binary run as a non-root user with just CAP_NET_ADMIN and CAP_NET_RAW permissions to cut the scope down even more.

[ryanjkirk]

Having not used setcap, would that also require the setuid bit to be set with ownership as root (like sudo)? And reside on a filesystem without the nosuid mount option?

[Reelin]

> would that also require the setuid bit to be set with ownership as root (like sudo)?

Doesn't setuid just change to whichever user owns the file? So with setuid root only needs to own it if you want full administrative privileges.

I also haven't played with setcap myself. My understanding is that capabilities don't rely on file ownership but instead on extended file attributes (which can't be changed by ordinary users on a correctly configured system). So root doesn't need to own the file, but of course granting any capabilities to a binary for which a non-root user has write permission seems like it would be a really bad idea in general.

> And reside on a filesystem without the nosuid mount option?

Yes, it appears the nosuid mount option disables file capabilities. (As one would hope!) But I'm not really seeing how that's an issue since (for example) bind mounts and btrfs subvolume mounts both allow changing the nosuid option.

(man 7 capabilities)

> 1. For all privileged operations, the kernel must check whether the thread has the required capability in its effective set.

> 2. The kernel must provide system calls allowing a thread's capability sets to be changed and retrieved.

> 3. The file system must support attaching capabilities to an executable file, so that a process gains those capabilities when the file is executed.

(https://wiki.archlinux.org/index.php/Capabilities)

> Capabilities are implemented on Linux using extended attributes (xattr(7)) in the security namespace.

(man 2 execve)

> The capabilities of the program file (see capabilities(7)) are also ignored if any of the above are true.