Bugzilla – Bug 1223900
sddm: issue with XAUTHORITY
Last modified: 2024-06-05 18:23:03 UTC
In xfce I use redshift to adjust the monitor night color. If I use lightdm as displaymanager, redshift works normally. Typing the command: redshift -o gives the output: Trying location provider `geoclue2'... Using provider `geoclue2'. Using method `randr'. Waiting for current location to become available... etc... But if I use sddm as displaymanager, redshift doesn't work. Typing the command: redshift -o gives the output: Trying location provider `geoclue2'... Using provider `geoclue2'. Authorization required, but no authorization protocol specified Authorization required, but no authorization protocol specified `RANDR Query Version' returned error -1 Initialization of randr failed. Trying next method... Authorization required, but no authorization protocol specified Authorization required, but no authorization protocol specified X request failed: XOpenDisplay Initialization of vidmode failed. Trying next method... No more methods to try. The output of: strace redshift -o contains: access("/tmp/xauth_WYBTin", R_OK) = 0 openat(AT_FDCWD, "/tmp/xauth_WYBTin", O_RDONLY) = -1 EACCES (Permission denied) The failure of redshift is due to the fact that somehow it cannot access /tmp/xauth_WYBTin (the value of $XAUTHORITY) However such file is readable by the user running redshift and other xprograms work fine. Leap 15.5 (sddm 0.19) works fine as did the previous versions. The issue started with sddm 0.20 (https://build.opensuse.org/package/show/openSUSE:Factory/sddm?rev=64) and is currently present in Leap 15.6 and tumbleweed. I could not figure out what exactly in sddm 0.20 is causing the problem.
Maybe redshift is setuid or it gets blocked by apparmor or selinux? You can check audit.log for the latter.
redshift is not setuid. Checking audit.log, it shows that access to /tmp/xauth_WYBTin by redshift is blocked by apparmor: (type=AVC msg=audit(1715098104.764:292): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/redshift" name="/tmp/xauth_gwENRi" pid=6051 comm="redshift" requested_mask="r" denied_mask="r" fsuid=6205 ouid=6205) But I fail to understand why if I compile and install on Leap 15.6 sddm 0.19 redshift works. Could you please add a apparmor expert in the loop?
I figured out what exactly the problem is. redshift provides a apparmor profile: /etc/apparmor.d/usr.bin.redshift such profile include: <abstractions/X> Which in turn grant access to the xauth file: owner @{HOME}/.Xauthority r, owner @{HOME}/.local/share/sddm/.Xauthority r, owner @{run}/gdm{,3}/*/database r, owner @{run}/lightdm/authority/[0-9]* r, owner @{run}/lightdm/*/xauthority r, owner @{run}/user/*/gdm/Xauthority r, owner @{run}/user/*/X11/Xauthority r, owner @{run}/user/*/xauth_* r, sddm up to 0.19 was putting the xauth file in: @{run}/user/*/xauth_* Since 0.20 the xauth file is located in: /tmp/xauth_[A-Za-z]* which is not included in any apparmor's abstracion file. Possible solutions are (in my preferred order): 1) revert the change in sddm and put the xauth file in the previous location 2) add in the apparmor's profile abstractions/X an entry for sddm's new xauth file location 3) add in redshift's profile such entry. I can prepare a SR for redshift to fix the issue but that's only a workaround. Some other programs that are using abstractions/X profile to allow access to the user's xauth file will have the same problem. Solution 1 or 2 is the appropriate fix.
Reassigning. It's basically bug 1174290 again.
There are at least two more entries that should go in <abstractions/X>: owner /tmp/xauth_* r, (for sddm) owner @{run}/user/*/.mutter-Xwaylandauth.* (for gnome on Xwayland)
(In reply to Giacomo Comes from comment #5) > There are at least two more entries that should go in <abstractions/X>: > > owner /tmp/xauth_* r, (for sddm) Agreed, even if "yet another path" is annoying. Submitted upstream as https://gitlab.com/apparmor/apparmor/-/merge_requests/1249 I'll also include the patch in the next submission to Tumbleweed. > owner @{run}/user/*/.mutter-Xwaylandauth.* (for gnome on Xwayland) That rule already exists since 2020. Do you have any audit.log entries that show issues with this file?
This is an autogenerated message for OBS integration: This bug (1223900) was mentioned in https://build.opensuse.org/request/show/1178600 Factory / apparmor
> > owner @{run}/user/*/.mutter-Xwaylandauth.* (for gnome on Xwayland) > > That rule already exists since 2020. Do you have any audit.log entries that > show issues with this file? You are right, my mistake. The rule is already there. I was having trouble with redshift on gnome on wayland, but it turns out the issue was unrelated to XAUTHORITY and apparmor.
Thanks for the feedback! That only leaves /tmp/xauth_*, which I already submitted - and that means I can close this bug as fixed :-)