That's intentional and was part of the libXau PR already. It was in /run/user/... initially but that proved to be problematic:

- On FreeBSD, $XDG_RUNTIME_DIR is an afterthought and only created/set as part of the graphical session itself
- If $XDG_RUNTIME_DIR is not available, a fallback is needed anyway
- Cleanup needs to be performed after session exit but still as unprivileged user, which is currently not easily possible with sddm-helper's design

Is there any particular issue with having the file in /tmp instead?

That commit touches the code for the greeter cookie only and doesn't actually change the location either:

-    m_authPath = QStringLiteral("%1/%2").arg(m_authDir).arg(QUuid::createUuid().toString(QUuid::WithoutBraces));
-    qDebug() << "Xauthority path:" << m_authPath;
+    m_authFile.setFileTemplate(m_authDir + QStringLiteral("/xauth_XXXXXX")); 

It's inside m_authDir in both cases.

(In reply to Fabian Vogt from comment #1)
> 
> Is there any particular issue with having the file in /tmp instead?
> 

Not for me (although $XDG_TUNTIME_DIR /feels/ more clean). But there are users who  try to start graphical programs from outside of GUI sessions; in this case it complicates things. I guess you better ask OP in this thread

https://lists.opensuse.org/archives/list/support@lists.opensuse.org/thread/PDA4D72XJKAHTOUHWT7QMPMNPUVXADWN/

(In reply to Andrei Borzenkov from comment #2)
> (In reply to Fabian Vogt from comment #1)
> > 
> > Is there any particular issue with having the file in /tmp instead?
> 
> Not for me (although $XDG_TUNTIME_DIR /feels/ more clean

Agreed.

). But there are
> users who  try to start graphical programs from outside of GUI sessions; in
> this case it complicates things. I guess you better ask OP in this thread
> 
> https://lists.opensuse.org/archives/list/support@lists.opensuse.org/thread/
> PDA4D72XJKAHTOUHWT7QMPMNPUVXADWN/

There's an easy way to run it in the proper environment: systemd-run --user.

e.g. systemd-run --user -P x11vnc.

This will pick up $DISPLAY, $XAUTHORITY and even $WAYLAND_DISPLAY.

When $XAUTHORITY file is in /tmp, it is subject to automated system-wide /tmp cleanup. For example in Tumbleweed file is removed after 10 days causing inabillity to start new applications within that session after 10 days.

(In reply to Juha Virtanen from comment #4)
> When $XAUTHORITY file is in /tmp, it is subject to automated system-wide
> /tmp cleanup. For example in Tumbleweed file is removed after 10 days
> causing inabillity to start new applications within that session after 10
> days.

It shouldn't be, but is anyway because of systemd behaviour: https://github.com/sddm/sddm/pull/1805

For me it seems like /usr/lib/tmpfiles.d/sddm.conf is ignored:

5 systemd-analyze cat-config tmpfiles.d | grep " /tmp/"
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
R! /tmp/systemd-private-*
D! /tmp/.X11-unix 1777 root root 10d
D! /tmp/.ICE-unix 1777 root root 10d
D! /tmp/.XIM-unix 1777 root root 10d
D! /tmp/.font-unix 1777 root root 10d
r! /tmp/.X[0-9]*-lock
$ cat  /usr/lib/tmpfiles.d/sddm.conf 
# Home dir of the sddm user, also contains state.conf
d       /var/lib/sddm   0750    sddm    sddm
# This contains X11 auth files passed to Xorg and the greeter
d       /run/sddm       0711    root    root
# Sockets for IPC
r!      /tmp/sddm-auth*
# xauth files passed to user sessions
r!      /tmp/xauth_*

I think, like Github discussion also seems to do, that sddm.conf should also have line

X /tmp/xauth_* - - - -

(In reply to Fabian Vogt from comment #5)
>> 
> It shouldn't be,

Why?

r! means "ignore this line if called during run-time". Nothing more, nothing less. It was never documented as "mark this file to be never removed during cleanup". There is documented way to do it - X - which you still refuse to accept.

r! simply guards against accidental invocation of "systemd-tmpfiles --remove" at the "wrong" time.

It is causing real problems to real users. It is up to you as upstream maintainer to accept or not accept it upstream, but as openSUSE maintainer I see no justification for refusing to apply this patch.

(In reply to Andrei Borzenkov from comment #7)
> It is causing real problems to real users. It is up to you as upstream
> maintainer to accept or not accept it upstream, but as openSUSE maintainer I
> see no justification for refusing to apply this patch.

Never did I refuse accepting the patch, I just wanted to make sure that
there is awareness and some discussion about this design flaw at the right place.

I did that myself now to finally unblock the PR:
https://github.com/systemd/systemd/issues/30361