<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 17, 2023 at 7:33 AM Tim Richardson <<a href="mailto:tim@tim-richardson.net">tim@tim-richardson.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div>In fact, the users having this problem mostly have in common that their session is started with a remote desktop session. <br></div><div>such as </div><div>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. <br></div><div><br></div><div>Comment 17 implies that the problem is the user session is not being setup correctly. <br></div><div><div><a href="https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17" target="_blank">https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17</a></div></div><div><br></div><div><br></div><div>An expert commentor <span role="gridcell"><span name="Maciej Borzecki"><span>Maciej Borzecki said: </span></span> </span></div><div style="margin-left:40px">I've commented before, but if your desktop session is correctly set up,<br>
the systemd --user instance should be available, then a transient scope<br>
can be created for snap and proper device access filtering can be set up<br>
in that cgroup, thus completing the sandbox. Cgroup v1 works<br>
differently, in that there is a separate hierarchy which could be set up<br>
for a snap and there's no need to ask ssytemd to set up anything on<br>
behalf of the snap. This is no longer the case for v2.<br>
<br>
AFAICT gdm/kdm/xdm seem to be able to do that correctly. Most trouble<br>
seems to be coming from X2go/vnc or similar solutions which appear to<br>
give you a desktop access, but it's half baked, and are either missing<br>
session dbus or the systemd --user instance. Perhaps it's not really<br>
going through PAM, hence things that would have been set up through<br>
pam_systemd are missing.</div><div><br></div><div><div>Specifically, the environment variable DBUS_SESSION_BUS_ADDRESS is not correct. <br></div><div><br></div><div>A typical fix is for users to do this:</div><div><br></div><div>export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"</div><div><br></div><div><br></div><div>before running the snap.</div><div>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.</div></div><div><br></div><div>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. <br></div><div><br></div><div>I think the problem is in the login stage, as Maciej says.<br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>(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.)<br></div><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>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. <br></div><div><br></div><div>x2go
 is barely maintained, which is a hint to me that the login process 
needs some kind of systemd enhancement missing in older code.<br></div><div><br></div><div>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</div><div><br></div><div>How could I prove to nomachine tech support that nomache workstation iis not logging in correctly?<br></div></div></blockquote><div><br></div><div>Compare the output of `loginctl` and maybe `cat /proc/self/cgroup` with what you see over e.g. SSH.</div><div><br></div><div>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")<br></div><div><br></div><div>Whereas if your processes are still inside x2go's "service" cgroup, that's an indication that it's not doing PAM setup correctly.<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>