[Question/Request] Use an active Network Namespace

[anzix]

Hello, I really like your program. It works very well on Plasma 6 Wayland, but I'm interested in using it in conjunction with my active Network Namespace (netns). Is it possible? I understand that ego under the hood calls the machinectl command which calls other commands. It seems like systemd-nspawn is responsible for all this, and judging by the documentation, it supports a parameter such as --network-namespace-path, which is equivalent to the NetworkNamespacePath parameter. I used the run0 (sudo alternative from systemd) command for native packages along with NetworkNamespacePath and BindReadOnlyPaths inside the --property parameter, which allowed me to use netns very comfortably.

Is the above-mentioned feasible in ego? Does such functionality make sense in your program?

[intgr]

Thanks for the feedback, it's always nice to hear that somebody finds this tool useful.

It would be trivial to take an ego --network-namespace-path=value argument and pass it on to machinectl.

It's taken so long to reply because I've been pondering the bigger picture:

1. There are tons more options supported by machinectl, I guess many of them might be useful to somebody. For future-proofing, it would make sense to create a more generic mechanism to these options, e.g. --machinectl-opt=network-namespace-path=value

2. Needing to pass this manual option every time you invoke ego seems unwieldy. Maybe in addition to command line flag, there should be support for defining default configuration, or "profiles" with configuration in a config file.

3. Could ego also help with creating and configuring this network namespace?

   I'm not at all familiar with this netns feature of Linux. It would be useful to know, what is your use case for network namespaces? What other use cases you could imagine? Do you use some other software to create and configure this namespace? Is there anything that ego could do to improve integration there, without too tight coupling? Maybe a hook to invoke an arbitrary command at launch, which could be configurable in profiles (2).

I think I should implement (1) regardless because it's straightforward; and (2)/(3) could be improvmenets added later (no promises that I ever get around to it).

[intgr]

Ahh! One thing I missed is that ego currently uses machinectl shell to swap privileges, but these options aren't supported by machinectl but instead systemd-nspawn. Will need to figure out if this gap can be bridged. (The lack of options in machinectl shell has also been an impediment for other features in the past.)

[anzix]

After a while, this feature request became less important to me because I was able to manually configure the XDG_RUNTIME_DIR and Wayland socket directories, plus X11 by simply using the setfacl command, without the need for ego. That's because I read the ego source code a little (even though I'm only familiar with the C language) and understood its work. And thanks to this, I was able to cope by passing the -u argument to the run0 command to select another user. And netns with another user in running Firefox everything works (except screen sharing using portal)

So I'm probably ok with the fact that this netns implementation for ego will be cumbersome. And as for me, you can reject this idea. Moreover, it is not critical for me now.

The created Network Namespace is an isolated network stack from the root Namespace (the current Linux network). And it can be created many times by placing interfaces created by tun with their own addresses and routes (for example, netns1 in Germany, netns2 in Russia, netns3 in the Netherlands)

And so here is my use case for Network Namespace:

I am running a sing-box (it can also be OpenVPN, Wireguard, ShadowSocks) on my system which runs the tun0 interface. Next, I create a netns vpn, then I throw this tun0 interface into the created namespace with the vpn name. Next, I assign an ip (from the sing-box json config) to this interface and activate tun0. I also activate the lo (loopback) interface, then add DNS for Netns vpn. And the main thing is that I add the tun0 interface route to the default network inside netns. After that, netns will be ready for use, as it was said through run0 and the parameter NetworkNamespacePath and BindReadOnlyPaths inside the --property parameter. Using a second user with netns, I am completely isolated from the external environment of my system and my recent tests on the Firefox browser have shown that it works very well, but not perfectly (as mentioned above about the problem with portal and screen sharing) on both X11/Xwayland and native Wayland

If you want to learn more about Network Namespace, please refer to this repository. Very good reading

Therefore, for me, the request for the netns function is now not as important as your efforts to investigate the work of the portal inside the second user