I’m installing telegram-desktop and trying to run it but it crashes just after loading taskbar icon. If I install using --devmode it’s works ok so assuming it’s the apparmor confinement that’s crashing it - logs would back this up.
Flatpak telegram-desktop also works but I’m trying to stick with snapd if I can.
Operating System: Manjaro Linux
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2
Kernel Version: 5.3.12-1-MANJARO
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz
Memory: 15.3 GiB of RAM
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
I used a snap before this called telega - it’s an el package for emacs and I authenticated with telegram servers and used it for an hour or so but then decided I wanted the desktop electron client instead.
As far as I know, /run/user/<uid>/.Xauthority was migrated from /tmp/*/.Xauthority for the given user by snap run. On my system with GDM, it’s at /run/user/<uid>/gdm/.Xauthority, but if you use some other display manager (xdm, sddm), the file may indeed be in /tmp, in which case it would get migrated.
Looking at the builtin interfaces, the x11 interface lists:
# Allow access to the user specific copy of the xauth file specified
# in the XAUTHORITY environment variable, that "snap run" creates on
owner /run/user/[0-9]*/.Xauthority r,
However, telegram-desktop snap does not use x11(?) and works correctly here:
Looks like the unity7 interface pulls in abstractions/X that allows accessing /run/user/<uid>/gdm/.Xauthority among others.
I see 2 ways of fixing this. First one is to have telegram-desktop use the x11 interface. Second, is perhaps extend the unity7 interface to allow access to migrated Xauthority file (cc @jdstrand). It already pulls in abstractions/X so migrated Xauthority being omitted feels like a bug.
The unity7 interface is historical and new policy is typically not added to it to encourage developers to move into the new style desktop interfaces. This is explained in some detail here: The desktop interfaces. The best course of action if for telegram-desktop to add x11, and I commented as such in the upstream bug.
While there is an argument that unity7 could be updated, please keep in mind the unity7 interface was designed to work with the unity 7 desktop environment and the known systems with unity 7 as the DE used an abstract socket for X instead of a named socket in /tmp. This bug is for KDE plasma on manjaro, not unity7 so a) it doesn’t surprise me that telegram-desktop not plugging x11 doesn’t work and b) as per the desktop interfaces, the x11, wayland, desktop and desktop-legacy interfaces were specifically added to support other DEs generically.
tbh - the conv is a bit over my head but thanks for this thread I’m starting to learn from it. t
Just to clarify from me, the bug isn’t confirmed yet by any other users apart from me. somebody spun up manjaro kde in a vm and snap installed telegram worked though they claimed they had to enable apparmor manually which doesn’t sound right to me.
What concerns me more is that there aren’t others reporting this as an issue. I’d image snapd on manjaro + KDE is a pretty common combo and telegram-desktop a popular application. That’s not to say it’s not an issue though, the telegram-desktop team have circa 1,180 issues to wade through which I consider quite high.
It could just be my set up but from the investigation and reinstalling I’ve done I can’t see how. Maybe apparmor could have got confused? as mentioned it’s working with --devmode.
From what I can tell (I’m not a telegram-desktop dev) telegram-desktop is written with qt5 as is KDE plasma so they’ve that in common. KDE plasma is using SDDM and X11 (at least for me). I’m not sure if that helps at all. I did try adding in a line to the apparmor profile for telegram-desktop and restarted apparmor but it made no difference…
So maybe the issue could be to do with apparmor. Does installing snapd install apparmor as a dependency and if so do you think removing apparmor completely and reinstalling it worth a try or something similar? Or would I be going up the wrong route with that…