yesterday's X issue - xauth is all that is needed.
This issue has been gnawing at me all day. It seems to me that Carlos' use case is so straight forward, it should Just Work (R), i.e. without magical incantations and mysterious work-arounds :-) xauth is all that is needed. I admit I have not yet fully grasped exactly what's going on: I have two systems - destination = toshiba1 with Leap 15.2 and KDE origin = office68 with Leap 15.3 and KDE When physically logged in on toshiba1: In: xauth generate :0 . Out: Invalid MIT-MAGIC-COOKIE-1 key Check results with "xauth list", there ought to be a new line with toshiba1/unix:0 MIT-MAGIC-COOKIE-1 <hexkey> Physically logged in on office68: ssh toshiba1 xauth list grab the hexkey, paste it here: xauth add :0 . hexkey With this, I can start an xclock from office68 on toshiba1 thus: ssh toshiba1 DISPLAY=:0 xclock I can also start e.g. okular, kmines, kicad, but firefox doesn't seem to quite work. At least I was unable to connect to an existing instance - when I tried with "--new-instance", I got a pop up about needing a new profile. Closing down the running firefox (on toshiba1), and it worked fine. By default, the generated key expires after 60 seconds of inactivity, but there is a timeout option. Just trying that out now. -- Per Jessen, Zürich (9.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 15.03.2023 20:26, Per Jessen wrote:
This issue has been gnawing at me all day. It seems to me that Carlos' use case is so straight forward, it should Just Work (R), i.e. without magical incantations and mysterious work-arounds :-)
Clients need authorization and pointing clients to $XAUTHORUTY used by X server is the most natural way, not a workaround.
xauth is all that is needed.
You can also use xhost to grant access to X server to every client or only local user/group.
I admit I have not yet fully grasped exactly what's going on:
I have two systems -
destination = toshiba1 with Leap 15.2 and KDE origin = office68 with Leap 15.3 and KDE
When physically logged in on toshiba1:
In: xauth generate :0 . Out: Invalid MIT-MAGIC-COOKIE-1 key
Check results with "xauth list", there ought to be a new line with toshiba1/unix:0 MIT-MAGIC-COOKIE-1 <hexkey>
Physically logged in on office68: ssh toshiba1 xauth list
grab the hexkey, paste it here:
Paste it where? You do not need this key on office68 and it is already present on toshiba.
xauth add :0 . hexkey
With this, I can start an xclock from office68 on toshiba1 thus:
ssh toshiba1 DISPLAY=:0 xclock
I can also start e.g. okular, kmines, kicad, but firefox doesn't seem to quite work. At least I was unable to connect to an existing instance - when I tried with "--new-instance", I got a pop up about needing a new profile. Closing down the running firefox (on toshiba1), and it worked fine.
By default authorization created by "xauth generate" is untrusted. Firefox instances communicate via X11 properties. Educated guess is that X server restricts access from untrusted client to the properties created by trusted clients (firefox started using "normal" $XAUTHORITY is trusted). You could try "xauth generate :0 . trusted".
By default, the generated key expires after 60 seconds of inactivity, but there is a timeout option. Just trying that out now.
Andrei Borzenkov wrote:
On 15.03.2023 20:26, Per Jessen wrote:
This issue has been gnawing at me all day. It seems to me that Carlos' use case is so straight forward, it should Just Work (R), i.e. without magical incantations and mysterious work-arounds :-)
Clients need authorization and pointing clients to $XAUTHORUTY used by X server is the most natural way, not a workaround.
As far as I can tell, XAUTHORITY does not need to be touched, it defaults to '~/.Xauthority'. Maybe in the newer TW setup ?
xauth is all that is needed.
You can also use xhost to grant access to X server to every client or only local user/group.
Yes, but as far as I can tell, that method is considered unsafe and/or deprecated. I did try it.
I admit I have not yet fully grasped exactly what's going on:
I have two systems -
destination = toshiba1 with Leap 15.2 and KDE origin = office68 with Leap 15.3 and KDE
When physically logged in on toshiba1:
In: xauth generate :0 . Out: Invalid MIT-MAGIC-COOKIE-1 key
Check results with "xauth list", there ought to be a new line with toshiba1/unix:0 MIT-MAGIC-COOKIE-1 <hexkey>
Physically logged in on office68: ssh toshiba1 xauth list
grab the hexkey, paste it here:
Paste it where?
xauth add :0 . hexkey ^^^^^^
You do not need this key on office68 and it is already present on toshiba.
I'll try it without the above, but that doesn't seem logical.
By default authorization created by "xauth generate" is untrusted. Firefox instances communicate via X11 properties. Educated guess is that X server restricts access from untrusted client to the properties created by trusted clients (firefox started using "normal" $XAUTHORITY is trusted). You could try "xauth generate :0 . trusted".
Hmm, yep, that sounds like some worth trying. -- Per Jessen, Zürich (5.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 15.03.2023 22:15, Per Jessen wrote:
Andrei Borzenkov wrote:
On 15.03.2023 20:26, Per Jessen wrote:
This issue has been gnawing at me all day. It seems to me that Carlos' use case is so straight forward, it should Just Work (R), i.e. without magical incantations and mysterious work-arounds :-)
Clients need authorization and pointing clients to $XAUTHORUTY used by X server is the most natural way, not a workaround.
As far as I can tell, XAUTHORITY does not need to be touched, it defaults to '~/.Xauthority'. Maybe in the newer TW setup ?
There is no real isolation between X clients, so if someone knows the value of magic cookie, it is possible to access X server and snoop all other clients or inject information. So all display managers today put cookie in a file with random name. Clients started by display managers are considered "trusted" and inherit path to it via $XAUTHORITY. This offers slightly better privacy (hard to call it "security"). See "man Xserver", "-auth" option. The portable way to export cookie for "external consumption" is to run "xauth extract | xauth -f /some/known/file merge" as part of your X11 session and then use XAUTHORITY=/some/known/file for "external" clients started outside of your X11 session.
Andrei Borzenkov wrote:
On 15.03.2023 22:15, Per Jessen wrote:
Andrei Borzenkov wrote:
On 15.03.2023 20:26, Per Jessen wrote:
This issue has been gnawing at me all day. It seems to me that Carlos' use case is so straight forward, it should Just Work (R), i.e. without magical incantations and mysterious work-arounds :-)
Clients need authorization and pointing clients to $XAUTHORUTY used by X server is the most natural way, not a workaround.
As far as I can tell, XAUTHORITY does not need to be touched, it defaults to '~/.Xauthority'. Maybe in the newer TW setup ?
There is no real isolation between X clients, so if someone knows the value of magic cookie, it is possible to access X server and snoop all other clients or inject information. So all display managers today put cookie in a file with random name.
Aha. That is presumably that /run/user/UID/xauth... that Pit mentioned in this posting yesterday ? Although I guess "today" should be read to mean "as of leap 15.4" ?
Clients started by display managers are considered "trusted" and inherit path to it via $XAUTHORITY. This offers slightly better privacy (hard to call it "security"). See "man Xserver", "-auth" option.
I'll check it out.
The portable way to export cookie for "external consumption" is to run "xauth extract | xauth -f /some/known/file merge"
Yeah, I saw that mentioned on the man page and I tried it - I couldn't get it to work, at least not the example that is mentioned on the man page: "xauth extract :0 - | ssh xauth merge -" -- Per Jessen, Zürich (4.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Thu, Mar 16, 2023 at 11:06 AM Per Jessen <per@jessen.ch> wrote:
The portable way to export cookie for "external consumption" is to run "xauth extract | xauth -f /some/known/file merge"
You conveniently trimmed "as part of your X11 session".
Yeah, I saw that mentioned on the man page and I tried it - I couldn't get it to work, at least not the example that is mentioned on the man page:
"xauth extract :0 - | ssh xauth merge -"
How magic cookie from X server on one host is going to help you to access X server on another host? This example is for ssh X forwarding to allow clients on *remote* host access X server on *local* host via ssh tunnel.
Andrei Borzenkov wrote:
On Thu, Mar 16, 2023 at 11:06 AM Per Jessen <per@jessen.ch> wrote:
The portable way to export cookie for "external consumption" is to run "xauth extract | xauth -f /some/known/file merge"
You conveniently trimmed "as part of your X11 session".
Sorry, it wasn't intentional - but isn't that exactly what I have done: running "xauth extract " on "origin", then merging it on "destination" ?
Yeah, I saw that mentioned on the man page and I tried it - I couldn't get it to work, at least not the example that is mentioned on the man page:
"xauth extract :0 - | ssh xauth merge -"
How magic cookie from X server on one host is going to help you to access X server on another host?
This example is for ssh X forwarding to allow clients on *remote* host access X server on *local* host via ssh tunnel.
Well, I have obviously misunderstood - it seemed to me that I was taking something from "origin" (= office68) and adding it to "destination" (= toshiba1), in the hope of enabling "origin" to start an X-app on "destination". -- Per Jessen, Zürich (5.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Thu, Mar 16, 2023 at 11:56 AM Per Jessen <per@jessen.ch> wrote:
Yeah, I saw that mentioned on the man page and I tried it - I couldn't get it to work, at least not the example that is mentioned on the man page:
"xauth extract :0 - | ssh xauth merge -"
How magic cookie from X server on one host is going to help you to access X server on another host?
This example is for ssh X forwarding to allow clients on *remote* host access X server on *local* host via ssh tunnel.
Well, I have obviously misunderstood - it seemed to me that I was taking something from "origin" (= office68) and adding it to "destination" (= toshiba1), in the hope of enabling "origin" to start an X-app on "destination".
"Start an X-app on" is completely ambiguous. host1> xcalc -display host2:0 Do you start X-app on host1 or host2? Binary runs on host1, output and input are on host2. Yes, your command enables you to run binaries on destination with input/output connected to X server on origin. So colloquially speaking it does enable origin to [allow to] start X-app on destination. It has nothing to do with running binaries on destination with input/output connected to X server on *destination* which was the original question.
On 16/03/2023 10:15, Andrei Borzenkov wrote:
Well, I have obviously misunderstood - it seemed to me that I was taking something from "origin" (= office68) and adding it to "destination" (= toshiba1), in the hope of enabling "origin" to start an X-app on "destination".
"Start an X-app on" is completely ambiguous.
host1> xcalc -display host2:0
Do you start X-app on host1 or host2? Binary runs on host1, output and input are on host2.
"Start an X-app on" was meant to be read in the meaning of Carlos' original question - starting firefox over ssh on a remote system (his media system?), with output to the remote display. Starting an X-app on host1 and directing the output to host2 - dunno what I would call that.
Yes, your command enables you to run binaries on destination with input/output connected to X server on origin. So colloquially speaking it does enable origin to [allow to] start X-app on destination.
Hmm, that is clearly not what I want, and it also seems much easier to achieve with 'ssh -X' ?
It has nothing to do with running binaries on destination with input/output connected to X server on *destination* which was the original question.
Right - that is what I want and what I achieved yesterday, even if I don't seem to have understood what I was doing. You seem to have a much better grasp of this - can you describe what I need to do - with xauth - to run 'xclock' over ssh on "destination", with output to destination, but all done from 'origin' : on origin: ssh destination DISPLAY=:0 xclock thanks Per
On Thu, Mar 16, 2023 at 12:43 PM Per Jessen <per@jessen.ch> wrote:
Yes, your command enables you to run binaries on destination with input/output connected to X server on origin. So colloquially speaking it does enable origin to [allow to] start X-app on destination.
Hmm, that is clearly not what I want, and it also seems much easier to achieve with 'ssh -X' ?
ssh -X only affects the communication channel (tunnel instead of direct connection). It changes nothing in requiring the X11 client to have a valid authentication token for the X11 server. It is just that ssh implicitly forwards xauth from origin to destination, so you do not notice it. I need to check something on xauth, which I'll do later tonight.
On 2023-03-16 11:43, Andrei Borzenkov wrote:
On Thu, Mar 16, 2023 at 12:43 PM Per Jessen <per@jessen.ch> wrote:
Yes, your command enables you to run binaries on destination with input/output connected to X server on origin. So colloquially speaking it does enable origin to [allow to] start X-app on destination.
Hmm, that is clearly not what I want, and it also seems much easier to achieve with 'ssh -X' ?
ssh -X only affects the communication channel (tunnel instead of direct connection). It changes nothing in requiring the X11 client to have a valid authentication token for the X11 server. It is just that ssh implicitly forwards xauth from origin to destination, so you do not notice it.
I need to check something on xauth, which I'll do later tonight.
There is another problem with ssh that appeared on 15.4: cer@Telcontar:~> ssh -X cer@isengard.valinor Last login: Thu Mar 16 11:45:20 2023 from 192.168.1.14 Have a lot of fun... dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.InvalidArgs: Invalid environment assignments cer@Isengard:~> No idea what it means or entails. "xeyes" runs as expected on remote machine and displays on local. cer@Telcontar:~> ssh cer@isengard.valinor Last login: Thu Mar 16 12:03:56 2023 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thu, Mar 16, 2023 at 2:07 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
There is another problem with ssh that appeared on 15.4:
cer@Telcontar:~> ssh -X cer@isengard.valinor Last login: Thu Mar 16 11:45:20 2023 from 192.168.1.14 Have a lot of fun... dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.InvalidArgs: Invalid environment assignments cer@Isengard:~>
No idea what it means or entails.
On 2023-03-16 12:10, Andrei Borzenkov wrote:
On Thu, Mar 16, 2023 at 2:07 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
There is another problem with ssh that appeared on 15.4:
cer@Telcontar:~> ssh -X cer@isengard.valinor Last login: Thu Mar 16 11:45:20 2023 from 192.168.1.14 Have a lot of fun... dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.InvalidArgs: Invalid environment assignments cer@Isengard:~>
No idea what it means or entails.
Oh, thanks. For those reading it, make sure you also read the github link on the first comment. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Andrei Borzenkov wrote:
On Thu, Mar 16, 2023 at 12:43 PM Per Jessen <per@jessen.ch> wrote:
Yes, your command enables you to run binaries on destination with input/output connected to X server on origin. So colloquially speaking it does enable origin to [allow to] start X-app on destination.
Hmm, that is clearly not what I want, and it also seems much easier to achieve with 'ssh -X' ?
ssh -X only affects the communication channel (tunnel instead of direct connection). It changes nothing in requiring the X11 client to have a valid authentication token for the X11 server. It is just that ssh implicitly forwards xauth from origin to destination, so you do not notice it.
Ah, I thought the forwarding of xauth was enabled with -X.
I need to check something on xauth, which I'll do later tonight.
Thanks. -- Per Jessen, Zürich (14.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 16.03.2023 12:43, Per Jessen wrote:
You seem to have a much better grasp of this - can you describe what I need to do - with xauth - to run 'xclock' over ssh on "destination", with output to destination, but all done from 'origin' :
on origin: ssh destination DISPLAY=:0 xclock
TL;DR: Either xauth is redundant or xauth is not enough under original conditions. If X server needs authentication, then each client needs to authenticate itself. xauth is just a X11 client as any other, so to perform "xauth generate" which contacts X server xauth already must be able to access X server. This is chicken and egg issue, In your example the valid shared secret ("magic cookie") was already present in ~/.Xauthority so no xauth invocation was needed at all. The only result was replacing trusted cookie generated by display manager with temporary cookie valid for the limited time. If display manager writes magic cookie into some other location, then your example simple would not work unless you made this location known to xauth (via XAUTHORITY or "xauth -f ...") but if you already know the correct location, you do not need xauth in the first place. bor@10:~> xauth generate :0 . Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified xauth: (argv):1: unable to open display ":0". bor@10:~> So obtaining path to the file where the valid magic cookie is stored and exporting it via XAUTHORITY is the only way unless you prepared your X server in advance (by using xhost, or by exporting the correct magic cookie or some other way). The *file* where it is stored does not really matter - the content of this file is what matters. P.S. on Leap 15.4 lightdm by default stores magic cookie in ~/.Xauthority file (it also stores it in private lightdm location, but it is not accessible to user). P.P.S. "generate" is the only operation that actually contacts X server; all other options work on existing files which again means that to extract correct cookie you already have to know the file where it is stored.
On Thu, 16 Mar 2023 12:15:47 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
"Start an X-app on" is completely ambiguous.
host1> xcalc -display host2:0
Do you start X-app on host1 or host2? Binary runs on host1, output and input are on host2.
Indeed so, and for better or for worse the correct terminology is 'client', or maybe 'X client' not 'X-app' ! :( And I appreciate that's Per's abomination, not yours :)
On 2023-03-16 12:49, Dave Howorth wrote:
On Thu, 16 Mar 2023 12:15:47 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
"Start an X-app on" is completely ambiguous.
host1> xcalc -display host2:0
Do you start X-app on host1 or host2? Binary runs on host1, output and input are on host2.
Indeed so, and for better or for worse the correct terminology is 'client', or maybe 'X client' not 'X-app' ! :( And I appreciate that's Per's abomination, not yours :)
There is a use case for running the program in local machine, displaying in remote machine (keyboard/mouse local, sound remote). It has a name, that's "casting". You can do that with VLC and suitable hardware on destination, like a Google Chromecast. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 15.03.2023 22:15, Per Jessen wrote:
You can also use xhost to grant access to X server to every client or only local user/group.
Yes, but as far as I can tell, that method is considered unsafe and/or deprecated.
Considered by whom? What exactly makes it less safe than magic cookie?
On 2023-03-15 18:26, Per Jessen wrote:
This issue has been gnawing at me all day. It seems to me that Carlos' use case is so straight forward, it should Just Work (R), i.e. without magical incantations and mysterious work-arounds :-)
xauth is all that is needed. I admit I have not yet fully grasped exactly what's going on:
I have two systems -
destination = toshiba1 with Leap 15.2 and KDE origin = office68 with Leap 15.3 and KDE
When physically logged in on toshiba1:
In: xauth generate :0 . Out: Invalid MIT-MAGIC-COOKIE-1 key
Check results with "xauth list", there ought to be a new line with toshiba1/unix:0 MIT-MAGIC-COOKIE-1 <hexkey>
Physically logged in on office68: ssh toshiba1 xauth list
grab the hexkey, paste it here: xauth add :0 . hexkey
With this, I can start an xclock from office68 on toshiba1 thus:
ssh toshiba1 DISPLAY=:0 xclock
I can also start e.g. okular, kmines, kicad, but firefox doesn't seem to quite work. At least I was unable to connect to an existing instance - when I tried with "--new-instance", I got a pop up about needing a new profile. Closing down the running firefox (on toshiba1), and it worked fine.
Well, yes, precisely! Firefox is different! That's why I asked last September, because the methods I knew or googled about didn't work with Firefox. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-03-15 18:26, Per Jessen wrote:
This issue has been gnawing at me all day. It seems to me that Carlos' use case is so straight forward, it should Just Work (R), i.e. without magical incantations and mysterious work-arounds :-)
I found a new issue, I think related. In the XFCE shipped with 15.2 there was a bug, a memory hole in "xfce4-panel", which eventually ate all memory and swap. The hack was to put in cron a job to do: xfce4-panel -r In order for this to work in cron, the actual line was: SHELL=/bin/bash MAILTO="cer" # min hour day Month week_day 0=7=sunday. 20 06 * * 7 DISPLAY=:0 xfce4-panel -r But now this hack fails. I got the failure email which I noticed now: Date: Sun, 12 Mar 2023 06:20:01 +0100 (CET) From: "(Cron Daemon)" <cer@Isengard.Valinor> To: cer@Isengard.Valinor Subject: Cron <cer@Isengard> DISPLAY=:0 xfce4-panel -r Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified xfce4-panel: Cannot open display: . Type "xfce4-panel --help" for usage. Maybe the cure is the same as I am using for firefox. However, I will for the moment disable the cronjob, because perhaps the memory hole bug has been solved (machine is now on 15.4). But you see, something has changed in 15.4 that made the ssh firefox trigger and this cronjob to fail. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Date: Sun, 12 Mar 2023 06:20:01 +0100 (CET) From: "(Cron Daemon)" <cer@Isengard.Valinor> To: cer@Isengard.Valinor Subject: Cron <cer@Isengard> DISPLAY=:0 xfce4-panel -r
Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified xfce4-panel: Cannot open display: . Type "xfce4-panel --help" for usage.
Maybe the cure is the same as I am using for firefox. However, I will for the moment disable the cronjob, because perhaps the memory hole bug has been solved (machine is now on 15.4).
But you see, something has changed in 15.4 that made the ssh firefox trigger and this cronjob to fail.
If the location of xauthority has changed (to /run/user/UID/xauth-etc), and applications don't know about this or rely on a default of ~/.Xauthority, that is perhaps the problem. On my TW system, if I run "xauth list" it only looks at ~/.Xauthority. If I alter XAUTHORITY it looks at that. As Pit suggested, one work-around is probably to point XAUTHORITY to the right location, but if/when the default location has changed, surely the default setting ought to be changed too. In your cronjob, you think you probably test that with: XAUTHORITY=/run/user/$UID/xauth* <cronjob spec> I think you can substitute XDG_RUNTIME_DIR for /run/user/$UID/ : XAUTHORITY=$XDG_RUNTIME_DIR/xauth* <cronjob spec> -- Per Jessen, Zürich (4.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-16 09:27, Per Jessen wrote:
Carlos E. R. wrote:
Date: Sun, 12 Mar 2023 06:20:01 +0100 (CET) From: "(Cron Daemon)" <cer@Isengard.Valinor> To: cer@Isengard.Valinor Subject: Cron <cer@Isengard> DISPLAY=:0 xfce4-panel -r
Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified xfce4-panel: Cannot open display: . Type "xfce4-panel --help" for usage.
Maybe the cure is the same as I am using for firefox. However, I will for the moment disable the cronjob, because perhaps the memory hole bug has been solved (machine is now on 15.4).
But you see, something has changed in 15.4 that made the ssh firefox trigger and this cronjob to fail.
If the location of xauthority has changed (to /run/user/UID/xauth-etc), and applications don't know about this or rely on a default of ~/.Xauthority, that is perhaps the problem.
cer@Isengard:~> l .Xauthority -rw------- 1 cer users 529 Mar 16 11:45 .Xauthority cer@Isengard:~> cat .Xauthority ��MIT-MAGIC-COOKIE-1/...Isengard18MIT-MAGIC-COOKIE-1= ...Isengard17MIT-MAGIC-COOKIE-1...Isengard14MIT-MAGIC-COOKIE-1...Isengard13MIT-MAGIC-COOKIE-1...Isengard15MIT-MAGIC-COOKIE-...*Isengard12MIT-MAGIC-COOKIE-1;...Isengard0MIT-MAGIC-COOKIE-...Isengard11MIT-MAGIC-COOKIE-1...Isengard10MIT-MAGIC-COOKIE-...cer@Isengard:~> Which is not the same as: cer@Isengard:~> cat $XDG_RUNTIME_DIR/xauth* Isengard0MIT-MAGIC-COOKIE-...MIT-MAGIC-COOKIE-...cer@Isengard:~> maybe some of the hidden (edited) chars are the same.
On my TW system, if I run "xauth list" it only looks at ~/.Xauthority. If I alter XAUTHORITY it looks at that.
As Pit suggested, one work-around is probably to point XAUTHORITY to the right location, but if/when the default location has changed, surely the default setting ought to be changed too.
In your cronjob, you think you probably test that with:
XAUTHORITY=/run/user/$UID/xauth* <cronjob spec>
I think you can substitute XDG_RUNTIME_DIR for /run/user/$UID/ :
XAUTHORITY=$XDG_RUNTIME_DIR/xauth* <cronjob spec>
Ok, thanks. I will write that on the cronjob, but not activate it till I know if the memory hole bug is still active in xfce4-panel -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
cer@Isengard:~> l .Xauthority -rw------- 1 cer users 529 Mar 16 11:45 .Xauthority cer@Isengard:~> cat .Xauthority ��MIT-MAGIC-COOKIE-1/...Isengard18MIT-MAGIC-COOKIE-1= ...Isengard17MIT-MAGIC-COOKIE-1...Isengard14MIT-MAGIC-COOKIE-1...Isengard13MIT-MAGIC-COOKIE-1...Isengard15MIT-MAGIC-COOKIE-...*Isengard12MIT-MAGIC-COOKIE-1;...Isengard0MIT-MAGIC-COOKIE-...Isengard11MIT-MAGIC-COOKIE-1...Isengard10MIT-MAGIC-COOKIE-...cer@Isengard:~>
Which is not the same as:
cer@Isengard:~> cat $XDG_RUNTIME_DIR/xauth* Isengard0MIT-MAGIC-COOKIE-...MIT-MAGIC-COOKIE-...cer@Isengard:~>
maybe some of the hidden (edited) chars are the same.
The way to list the contents is with 'xauth list', e.g. xauth -f $XDG_RUNTIME_DIR/xauth* list What would be nice to know is the relationship between those two. Clearly one is for runtime only - I'm wondering if it is created when you log in, based on ~/.Xauthority. -- Per Jessen, Zürich (15.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
The way to list the contents is with 'xauth list', e.g.
xauth -f $XDG_RUNTIME_DIR/xauth* list
What would be nice to know is the relationship between those two. Clearly one is for runtime only - I'm wondering if it is created when you log in, based on ~/.Xauthority.
If I list the ~/.Xauthority that way, I do see a bunch of entries from ssh -X logins (DISPLAY number above 10). There is also one for DISPLAY :0, but that is a (very?) old one. Definitely not the one belonging to the currently running session. If I try to use it: lux:~% XAUTHORITY=~/.Xauthority xterm Invalid MIT-MAGIC-COOKIE-1 key Invalid MIT-MAGIC-COOKIE-1 key xterm: Xt error: Can't open display: :0 I *suspect* that the entry for :0 comes from a remote display login using x11vnc_ssh - I'll try to verify that tomorrow.
On 2023-03-16 16:24, Pit Suetterlin wrote:
Per Jessen wrote:
The way to list the contents is with 'xauth list', e.g.
xauth -f $XDG_RUNTIME_DIR/xauth* list
What would be nice to know is the relationship between those two. Clearly one is for runtime only - I'm wondering if it is created when you log in, based on ~/.Xauthority.
If I list the ~/.Xauthority that way, I do see a bunch of entries from ssh -X logins (DISPLAY number above 10). There is also one for DISPLAY :0, but that is a (very?) old one. Definitely not the one belonging to the currently running session.
If I try to use it:
lux:~% XAUTHORITY=~/.Xauthority xterm Invalid MIT-MAGIC-COOKIE-1 key Invalid MIT-MAGIC-COOKIE-1 key xterm: Xt error: Can't open display: :0
I *suspect* that the entry for :0 comes from a remote display login using x11vnc_ssh - I'll try to verify that tomorrow.
Similar here: cer@Telcontar:~> ssh -X cer@isengard.valinor Last login: Thu Mar 16 12:06:16 2023 from 192.168.1.14 Have a lot of fun... dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.InvalidArgs: Invalid environment assignments cer@Isengard:~> cer@Isengard:~> xauth -f $XDG_RUNTIME_DIR/xauth* list Isengard/unix:0 MIT-MAGIC-COOKIE-1 d549be295572e3e8e40112... #ffff##:0 MIT-MAGIC-COOKIE-1 d549be295572e3e8e40112... cer@Isengard:~> xauth -f ~/.Xauthority list #fffc##: MIT-MAGIC-COOKIE-1 2f8603a4d9d474bee64559... Isengard/unix:18 MIT-MAGIC-COOKIE-1 3d0a0910f3d76e3a7... Isengard/unix:17 MIT-MAGIC-COOKIE-1 a1bfe8173c3243b67... Isengard/unix:14 MIT-MAGIC-COOKIE-1 ac949eb01fa8e7f4e... Isengard/unix:13 MIT-MAGIC-COOKIE-1 0ff761c4a6f5d8c55... Isengard/unix:15 MIT-MAGIC-COOKIE-1 b35db16858980280c... Isengard/unix:12 MIT-MAGIC-COOKIE-1 3bdb47945ab32cec8... Isengard/unix:0 MIT-MAGIC-COOKIE-1 12a1c8b1867dea0174... Isengard/unix:11 MIT-MAGIC-COOKIE-1 49639288c0349bdb1... Isengard/unix:10 MIT-MAGIC-COOKIE-1 ea8efa7228d5db8d8... cer@Isengard:~> man says: info Information describing the authorization file, whether or not any changes have been made, and from where xauth commands are being read is printed on the standard output. cer@Isengard:~> xauth info Authority file: /home/cer/.Xauthority File new: no File locked: no Number of entries: 10 Changes honored: yes Changes made: no Current input: (argv):1 cer@Isengard:~> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-03-16 16:24, Pit Suetterlin wrote:
I *suspect* that the entry for :0 comes from a remote display login using x11vnc_ssh - I'll try to verify that tomorrow.
Similar here:
[snip] Indeed. I just checked two things: using ssh -X indeed adds a new entry to ~/.Xauthority, for the DISPLAY it uses. In that session, XAUTHORITY is *not* set, so ssh only uses xauth, and the default(?) ~/.Xauthority. I also tried to connect to my running session at home, using x11vnc_ssh (via the wrapper I posted earlier). Contrary to what I expected, this did *not* create an entry in ~/.Xauthority. Which actually is reasonable, it's just xvnc that needs the proper XAUTHORITY. That means that entry for display :0 had been *really* old, likely coming from the time before the displaymanager started using randomized xauth files....
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
Per Jessen -
Pit Suetterlin