I spend few hours trying to find why my non-console snaps fail to run with “Failed to connect display” message. I found that was due to
-nolisten local option which disables listening on abstract socket in Xorg display server.
I think it can be documented somewhere for new snap users.
That sounds to me like something you should research about via Xorg documentation before you add the
-nolisten local flag to your configuration. IMO it is not the remit of Snappy documentation to anticipate every esoteric hack that people make to their systems to account for the 0.1% (arbitrary guessed figure - real value may vary, but this is illustrative) who make those changes. “new snap users” are very unlikely to have made this modification to their systems, so documenting it in the getting started documentation will likely confuse them more than educate.
I did my research years ago when I enabled that config option. Meanwhile I used various sandboxing tools like flatpak, firejail, apparmor or whatever and there were no issues so snap is special case in this regard (I really think this should be fixed in snap). The problem is that when I did research about snaps I found nothing.
This being a corner case also means it’s hard to figure out. I spent few hours talking to snap devs until this idea occurred to me. Next time someone may fill a bug which won’t be resolved for days, months or even never.
Documenting such cases in form of checklist or “common errors” would prevent knowledge to be forgotten. Even if users won’t do a research themselves it will be easier for devs to ask right questions instead of trying to solve each puzzle from scratch.
For what it’s worth, Firefox 60+ uses the Xorg abstract socket. This feature has been deactivated on Snap. More details at https://bugzilla.mozilla.org/show_bug.cgi?id=1449594#c9. Like @oSoMoN said in comment 18, we might want to discuss the ability for a Snapped app to access
/tmp/.X11-unix. What do you all think?
I see disabling Xorg abstract socket as security precaution therefore removing dependence on it for snap would be an advantage. As I wrote above other sandboxing tools like flatpak, firejail, systemd-nspawn doesn’t need it. I think bind-mounting as read-only /tmp/.X11-unix inside sandbox can be a solution.
This came up on IRC yesterday. In terms of snapd:
11:08 < jdstrand> oSoMoN: we aren't avoiding the named socket for security reasons.
we just haven't needed it since the abstract is there
Basically, apparmor can mediate named or abstract socket just fine so there is no difference for full confinement. Since at least firefox needs the socket dir in /tmp, seems like the work need only be prioritized. @mvo and/or @zyga-snapd - perhaps you can add this to the roadmap?
So we need to bring a socket from /somehwere over to /tmp? Is that it?
To clarify: Firefox uses the normal X11 client libraries, which try both abstract and pathname addresses (in that order). This behavior of the Snap container broke Firefox 60+, because the content sandbox blocked abstract sockets for content processes by starting them in a new network namespace. The problem has been worked around by detecting the situation and turning off that layer of the sandbox, similar to what we have to do with remote or ssh-tunnelled X11.
(Longer-term we plan to stop connecting directly to the X server from content processes, because it’s a security problem, but I don’t think we have a concrete timeline for it yet.)
After some chatter on IRC I know how to solve this issue. It looks like one day of work with low risk of failure. I’ll let someone else schedule this but I can do it on demand.
Hi, @zyga-snapd . Any update on this?
No, I haven’t touched it yet. I will add it to my backlog for now.
Looks like there’s new demand for this, now that Mutter in the upcoming Ubuntu 20.10 dropped support for the abstract X11 socket in Wayland sessions.
This is fixed in snapd 2.48+ : https://github.com/snapcore/snapd/pull/9530
Note that AppArmor 3.0.0 has regression that makes using non-abstract socket impossible which is fixed in AppArmor 3.0.1