[systemd-devel] (no subject)

Tue Oct 17 06:01:08 UTC 2023

On Tue, Oct 17, 2023 at 7:33 AM Tim Richardson <tim at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20231017/133d9c91/attachment.htm>