[winswitch] -nolisten local

[Antoine Martin]

On 20/02/2024 23:49, Vinícius dos Santos Oliveira wrote:
> Em ter., 20 de fev. de 2024 às 05:28, Antoine Martin via shifter-users
> <shifter-users at lists.devloop.org.uk> escreveu:
>> On 14/02/2024 23:30, Vinícius dos Santos Oliveira via shifter-users wrote:
>>> How to make xpra add -nolisten local to Xorg invocation?
>> You can just add it to your Xvfb command line in /etc/xpra, see:
>> https://github.com/Xpra-org/xpra/blob/a3a51067e61d710d1f63b48e4bbffa66ff71ab83/fs/etc/xpra/conf.d/55_server_x11.conf.in#L32-L41
> 
> Does xpra depend on the X11 abstract socket?
No it does not.

> If not, why have it on as
> the default? Isn't it just the same as -nolisten tcp?
Comparing "tcp" and "asbtract sockets" is quite strange.

> I don't quite understand xpra's codebase. I tried to add -nolisten
> local after these two lines to adjust the default:
> 
> * https://github.com/Xpra-org/xpra/blob/05001bba3cd32b3ad9d24cccdac4f2911b0b26e3/xpra/scripts/config.py#L127
> * https://github.com/Xpra-org/xpra/blob/05001bba3cd32b3ad9d24cccdac4f2911b0b26e3/xpra/scripts/config.py#L147
> 
> However it doesn't work. Does it always use the files in /etc/xpra
> that you mentioned?
Why would you modify the source code instead of the configuration files?

>> Incidentally, xpra v6 supports abstract sockets:
>> https://github.com/Xpra-org/xpra/issues/4098
>> Which you can turn off with --bind=noabstract
> 
> This is an extra abstract socket not related to X11 socket, right?
Correct, these sockets are used by xpra itself.
This is fully documented - no need to read any source code:
https://github.com/Xpra-org/xpra/tree/master/docs/Network

>> The default is to use peercred to filter connections.
> 
> This won't work for Linux containers using unprivileged user
> namespaces. For unprivileged user namespaces you can only use/map your
> own UID so every container will have the same UID even if you're
> trying to create containers isolated from each other. Unprivileged
> user namespaces can't configure network stacks so you either disable
> the network completely or every container shares the same network
> namespace (and the same abstract UNIX socket addressing space).
Yes, some container setups come with constraints and limitations.
That is to be expected.

> These container limitations can be partially overcome by SUID helpers
> (e.g. newuidmap and slirp4netns). However it doesn't mean that
> peercreds alone for this purpose are safe. Enabling abstract sockets
> indiscriminately isn't safe. Users wishing to make use of the abstract
> UNIX sockets can proceed to do so only after careful planning taking
> the interactions of the system as a whole into consideration to make
> sure the feature will be safe.
No, we do not remove features simply because they may be misused in some 
context. If we did, there would be very little left.

You've inadvertently made the case for abstract sockets.
They allow for a different type of network connection, one that does not 
require a shared filesystem address, or a bind mount. This can actually 
be useful with containers.

One would expect those who use containers for isolation to understand 
the implications and limitations of unprivileged user namespaces.

Please add further comments to your (rejected) PR:
https://github.com/Xpra-org/xpra/pull/4154

Cheers,
Antoine



> --
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/