[systemd-devel] (no subject)

[Tim Richardson]

There is a long standing and long bug report in Ubuntu which attributes the
inability to start the Firefox snap (or any snap with sandboxing) to snapd.
In fact, the users having this problem mostly have in common that their
session is started with a remote desktop session.
such as
nomachine (workstation, which starts a virtual session) and x2go, and
sometimes various vnc connections, those which spawn remote sessions rather
than screen sharing an existing session, I suspect.

Comment 17 implies that the problem is the user session is not being setup
correctly.
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17


An expert commentor Maciej Borzecki said:
I've commented before, but if your desktop session is correctly set up,
the systemd --user instance should be available, then a transient scope
can be created for snap and proper device access filtering can be set up
in that cgroup, thus completing the sandbox. Cgroup v1 works
differently, in that there is a separate hierarchy which could be set up
for a snap and there's no need to ask ssytemd to set up anything on
behalf of the snap. This is no longer the case for v2.

AFAICT gdm/kdm/xdm seem to be able to do that correctly. Most trouble
seems to be coming from X2go/vnc or similar solutions which appear to
give you a desktop access, but it's half baked, and are either missing
session dbus or the systemd --user instance. Perhaps it's not really
going through PAM, hence things that would have been set up through
pam_systemd are missing.

Specifically, the environment variable DBUS_SESSION_BUS_ADDRESS is not
correct.

A typical fix is for users to do this:

export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"


before running the snap.
snaps are surfacing this problem for some reason but I don't think it is
snap problem. When the snap launches it finds itself in an unexpected
cgroup.

In one of my experiments, running systemd --user in a shell and starting a
snap from there worked. It was when I compared the environment generated
here vs the environment after logging in via nomachine that I discovered
the workaround of exporting that variable. But it is not a very good
workaround. It only allows one session per user, for instance.

I think the problem is in the login stage, as Maciej says.
I can't find documentation on how the "modern" login process works, at
least detailed enough to explain how you make sure the pam_systemd setup is
invoked. I got lost in the scripts trying to work it out.
I have no practical understanding of the login process, so I am bad person
to be asking this question, but no one else seems to trying. Just a lot of
complaining users adding to the bug report.

I use nomachine, and while I have mentioned my suspicions to their tech
support, I can't be very technically convincing since I don't understand
what has changed in the login process causing them to miss something.

x2go is barely maintained, which is a hint to me that the login process
needs some kind of systemd enhancement missing in older code.

Is there someone on this mailing list who can join the dots and give good
clues about what might be going wrong with the login process of nomachine,
x2go etc

How could I prove to nomachine tech support that nomache workstation iis
not logging in correctly?


-- 
Tim Richardson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20231017/becd89f3/attachment.htm>