Acknowledgement sent
to Ian Jackson <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian X Strike Force <[email protected]>.
(Sun, 06 Mar 2011 12:36:05 GMT) (full text, mbox, link).
Subject: X server crash due to "xauth generate" with large timeout
Date: Sun, 6 Mar 2011 12:32:21 +0000
Package: xserver-xorg
Version: 1:7.5+8
To reproduce:
cp .Xauthority private/tmpfile
xauth -f private/tmpfile generate $DISPLAY . untrusted timeout 1000000000
Actual behaviour:
My X server died. The log message was:
X: ../../Xext/security.c:323: SecurityAuthorizationExpired: Assertion `pAuth->timer == timer' failed.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 7385 requests (7224 known processed) with 0 events remaining.
Desired behaviour:
X auth cookie is replaced in private/tmpfile and X server does not
crash. Alternatively, an error message (eg, that the timeout is too
large, or that the X request failed).
I was trying to make an untrusted cookie which would not time out.
Unfortunately that does not appear to be possible. A timeout value of
1000000 seems to work; 10000000 crashes the server.
Ian.
Acknowledgement sent
to Cyril Brulebois <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Sun, 06 Mar 2011 13:39:06 GMT) (full text, mbox, link).
severity 616667 important
reassign 616667 xserver-xorg-core
found 616667 2:1.7.7-11
user [email protected]
usertag squeeze-candidate
thanks
Hi Ian,
Ian Jackson <[email protected]> (06/03/2011):
> Package: xserver-xorg
> Version: 1:7.5+8
>
> To reproduce:
> cp .Xauthority private/tmpfile
> xauth -f private/tmpfile generate $DISPLAY . untrusted timeout 1000000000
>
> Actual behaviour:
> My X server died. The log message was:
> X: ../../Xext/security.c:323: SecurityAuthorizationExpired: Assertion `pAuth->timer == timer' failed.
ouch. Tagging as something we might want to fix in squeeze (until it's
investigated anyway).
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
> after 7385 requests (7224 known processed) with 0 events remaining.
>
> Desired behaviour:
> X auth cookie is replaced in private/tmpfile and X server does not
> crash. Alternatively, an error message (eg, that the timeout is too
> large, or that the X request failed).
>
> I was trying to make an untrusted cookie which would not time out.
> Unfortunately that does not appear to be possible. A timeout value of
> 1000000 seems to work; 10000000 crashes the server.
With 2:1.9.99.903-1, I'm getting:
| -(cyril@talisker)-(/tmp)-()
| $ xauth -f private generate $DISPLAY . untrusted timeout 1000000000
| xauth: (argv):1: couldn't query Security extension on display ":42.0"
Will see if that's expected once I get some more info from a squeeze
system.
KiBi.
Acknowledgement sent
to Ian Jackson <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Sun, 06 Mar 2011 13:39:08 GMT) (full text, mbox, link).
Subject: Re: Bug#616667: X server crash due to "xauth generate" with large
timeout
Date: Sun, 6 Mar 2011 13:37:27 +0000
Cyril Brulebois writes ("Re: Bug#616667: X server crash due to "xauth generate" with large timeout"):
> With 2:1.9.99.903-1, I'm getting:
> | -(cyril@talisker)-(/tmp)-()
> | $ xauth -f private generate $DISPLAY . untrusted timeout 1000000000
> | xauth: (argv):1: couldn't query Security extension on display ":42.0"
>
> Will see if that's expected once I get some more info from a squeeze
> system.
"xauth generate" _replaces_ the cookie in the specified xauthority
file with an untrusted one. That error message is the one you get if
you _already_ have an untrusted cookie in your xauthority file - ie,
if you run "xauth generate" for the second time without running the
"cp" again.
If you ran xauth generate without the -f option then I'm afraid you
have busticated your session.
Of course it may be that that error message is also the one you get if
a fixed server rejects your big timeout, but that should be easy
enough to test ...
Ian.
Acknowledgement sent
to Cyril Brulebois <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Sun, 06 Mar 2011 15:30:03 GMT) (full text, mbox, link).
Ian Jackson <[email protected]> (06/03/2011):
> "xauth generate" _replaces_ the cookie in the specified xauthority
> file with an untrusted one. That error message is the one you get
> if you _already_ have an untrusted cookie in your xauthority file -
> ie, if you run "xauth generate" for the second time without running
> the "cp" again.
No. What I got was due to #599657, still affecting sid/experimental.
KiBi.
Acknowledgement sent
to Cyril Brulebois <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Sun, 06 Mar 2011 19:48:05 GMT) (full text, mbox, link).
forwarded 616667 https://bugs.freedesktop.org/show_bug.cgi?id=35066
thanks
Cyril Brulebois <[email protected]> (06/03/2011):
> ouch. Tagging as something we might want to fix in squeeze (until
> it's investigated anyway).
Either I screwed up the analysis, or that's a bit silly. See the
upstream bug report for more info. Patches went to xorg-devel@ a few
seconds ago.
I guess the upcoming fixes will be backported to 1.7 and 1.9 branches,
so will probably land in r2 (xorg-server for r1 has already been
uploaded, I'm not sure we're going to have time to perform a new
upload just for that bug — or if it's worth it anyway).
KiBi.
Acknowledgement sent
to Andrei Gudkov <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Wed, 21 Aug 2019 17:03:06 GMT) (full text, mbox, link).