On Tue, Oct 17, 2023 at 7:33 AM Tim Richardson <t...@tim-richardson.net> 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 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. > 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 etc > > How 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
