On Tue, Oct 17, 2023 at 7:33 AM Tim Richardson <tim@xxxxxxxxxxxxxxxxxx> wrote:
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 asnomachine (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.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.
The steps needed from login services are not any different from what it was before systemd, really. When a network service needs to verify a password, it loads libpam and calls "pam_authenticate()"; when it needs to verify the user's access rights it calls "pam_acct_mgmt()"; and when it needs to initialize the various environment for the freshly logged-in user, it calls "pam_open_session()". That's what sshd and /sbin/login and GDM have been doing for decades before systemd – pam_systemd is just one more module that's listed in /etc/pam.d/sshd.
It's probably safe to assume that x2go uses PAM already, so the first thing to check is whether it has the correct 'session' modules in /etc/pam.d/x2go or similar. On Ubuntu it should be including the "common-session" file. There *might* be some complications, e.g. it not passing some of the necessary fields to PAM, or calling pam_open_session() in the wrong process that makes it a no-op, or the process doing everything might immediately exit...
(For example, if the login is actually handled via SSH and not by X2go itself, then it might be a similar issue as with Mosh – sshd logs you in, creates a session, does everything properly... but the session immediately ends as its only purpose was to bootstrap mosh-server, and once that's running the client disconnects and sshd does pam_close_session() even though your apparent Mosh "login" has just begun. Although, with current systemd versions this at least leaves you a "closing" session, which is still better than nothing.)
As a last resort, you could ask systemd-logind to always keep your 'systemd --user' instance running by doing `loginctl enable-linger $USER`. That'll give you a permanently available $XDG_RUNTIME_DIR/bus and everything else, even if you're not logged in "correctly", though you'll still need to set $XDG_RUNTIME_DIR and such by hand. (The bus is only a means for snapd to access 'systemd --user', though.)
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 etcHow could I prove to nomachine tech support that nomache workstation iis not logging in correctly?
Compare the output of `loginctl` and maybe `cat /proc/self/cgroup` with what you see over e.g. SSH.
A "correct" login (i.e. one that goes through PAM) will have pam_systemd create you a "session" in systemd-logind and move your process to a fresh cgroup named after your UID, e.g. in cgroupv2 systems it would be "/user.slice/user-UID.slice/session-XXX.scope" (and everything that's launched via your 'systemd --user' would likewise be under ".../user-UID.slice/user@UID.service")
Whereas if your processes are still inside x2go's "service" cgroup, that's an indication that it's not doing PAM setup correctly.
--
Mantas Mikulėnas
