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.
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.
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
