https://bugs.kde.org/show_bug.cgi?id=491130
Matt Whitlock <k...@mattwhitlock.name> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |k...@mattwhitlock.name
--- Comment #6 from Matt Whitlock <k...@mattwhitlock.name> ---
Every KDE application I start emits this warning on stderr:
> Qt: Session management error: Authentication Rejected, reason :
> MIT-MAGIC-COOKIE-1 authentication rejected
Indeed, it appears as though the apps are failing to register with KSMServer.
If I start an app (e.g., KCalc) and then save my current session with a new
name…
> $ qdbus6 org.kde.ksmserver /KSMServer saveCurrentSessionAs bugtest
> $ sed -e '/bugtest/,/^$/!d' ~/.config/ksmserverrc
> [LegacySession: bugtest]
> count=0
>
> [Session: bugtest]
> count=0
There's nothing saved in the session. KCalc evidently did indeed fail to
authenticate with KSMServer.
Here's the relevant bit from an strace of KCalc's startup:
> socket(AF_UNIX, SOCK_STREAM, 0) = 14
> getsockopt(14, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
> uname({sysname="Linux", nodename="Crushinator", ...}) = 0
> connect(14, {sa_family=AF_UNIX, sun_path="@/tmp/.ICE-unix/4318"}, 22) = -1
> ENOENT (No such file or directory)
> close(14) = 0
> socket(AF_UNIX, SOCK_STREAM, 0) = 14
> getsockopt(14, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
> uname({sysname="Linux", nodename="Crushinator", ...}) = 0
> connect(14, {sa_family=AF_UNIX, sun_path="/tmp/.ICE-unix/4318"}, 21) = 0
> fcntl(14, F_SETFD, FD_CLOEXEC) = 0
> write(14, "\0\1\0\0\0\0\0\0", 8) = 8
> read(14, "\0\1\0H\0\0\0\0", 8) = 8
> access("/run/user/1000/iceauth_pnzFrq", R_OK) = 0
> openat(AT_FDCWD, "/run/user/1000/iceauth_pnzFrq", O_RDONLY) = 15
> fstat(15, {st_mode=S_IFREG|0600, st_size=338, ...}) = 0
> read(15,
> "\0\3ICE\0\0\0&local/Crushinator:@/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20\226J'\364\v\326m~\0\0\0\0\0\0\0\0\0\4XSMP\0\0\0&local/Crushinator:@/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20t\342\30E\351\16i\221\344\250\226W\213\24\252\26\0\3ICE\0\0\0$unix/Crushinator:/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20<S\226\341I\216R\17\34\0\0\0\0\0\0\0\0\4XSMP\0\0\0$unix/Crushinator:/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20<PCu\23\262\377\277\241\301
> Q\262d\f\4", 4096) = 338
> read(15, "", 4096) = 0
> close(15) = 0
> write(14,
> "\0\2\1\1\6\0\0\0\0\0\0\0\0\0\0\0\3\0MIT\0\0\0\3\0001.0\0\0\0\22\0MIT-MAGIC-COOKIE-1\1\0\0\0",
> 56) = 56
> read(14, "\0\3\0H\1\0\0\0", 8) = 8
> read(14, "\0\0\0\0\0\0\0\0", 8) = 8
> access("/run/user/1000/iceauth_pnzFrq", R_OK) = 0
> openat(AT_FDCWD, "/run/user/1000/iceauth_pnzFrq", O_RDONLY) = 15
> fstat(15, {st_mode=S_IFREG|0600, st_size=338, ...}) = 0
> read(15,
> "\0\3ICE\0\0\0&local/Crushinator:@/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20\226J'\364\v\326m~\0\0\0\0\0\0\0\0\0\4XSMP\0\0\0&local/Crushinator:@/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20t\342\30E\351\16i\221\344\250\226W\213\24\252\26\0\3ICE\0\0\0$unix/Crushinator:/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20<S\226\341I\216R\17\34\0\0\0\0\0\0\0\0\4XSMP\0\0\0$unix/Crushinator:/tmp/.ICE-unix/4318\0\22MIT-MAGIC-COOKIE-1\0\20<PCu\23\262\377\277\241\301
> Q\262d\f\4", 4096) = 338
> close(15) = 0
> write(14,
> "\0\4\1\1\3\0\0\0\20\0\0\0\0\0\0\0<S\226\341I\216R\17\34\0\0\0\0\0\0\0", 32)
> = 32
> read(14, "\0\0\4\0\7\0\0\0", 8) = 8
> read(14, "\4\1\0\0\3\0\0\0", 8) = 8
> read(14, "*\0MIT-MAGIC-COOKIE-1 authentication rejectedV\0\0\0", 48) = 48
> close(14) = 0
> write(2, "Qt: Session management error: Authentication Rejected, reason :
> MIT-MAGIC-COOKIE-1 authentication rejected\n", 107) = 107
Oddly, it appears as though KCalc first attempts to open a Unix socket
connection to path "@/tmp/.ICE-unix/4318". That's an invalid path. What it
apparently means to do is to connect to an abstract socket named
"/tmp/.ICE-unix/4318", but someone forgot to overwrite that ampersat with a
null byte. (`socat - ABSTRACT-CONNECT:/tmp/.ICE-unix/4318` does connect
successfully, so the abstract socket exists and is listening; KCalc just isn't
specifying the correct .sun_path for it.) But no matter: KCalc then falls back
to the pathname socket at /tmp/.ICE-unix/4318 and connects successfully.
After connecting to the ICE server (which is running inside KSMServer), KCalc
sends a ByteOrder declaration and reads the server's ByteOrder declaration.
(Why the ICE protocol didn't just specify a fixed byte order is anyone's
guess.) Then it opens and reads the magic cookie file located at
/run/user/1000/iceauth_pnzFrq, which does indeed exist and was last modified at
the time I started my Plasma X11 session. KCalc sends a ConnectionSetup message
that offers one version (1.0) with a vendor of "MIT" and a release of "1.0" and
one authentication protocol name ("MIT-MAGIC-COOKIE-1"). KCalc reads an
AuthenticationRequired reply that requests the MIT-MAGIC-COOKIE-1
authentication protocol. KCalc sends an AuthenticationReply message that
contains the magic cookie, which has the correct value as read from
/run/user/1000/iceauth_pnzFrq. KCalc reads an Error reply of class
AuthenticationRejected, concerning an AuthenticationReply message, of
FatalToProtocol severity, with the error message "MIT-MAGIC-COOKIE-1
authentication rejected".
So everything looks fine on the client side (other than the mistake in the
socket path handling). I am guessing something has become broken in KSMServer.
I am suspicious that the ICE magic cookies for my session both end in runs of
NUL bytes rather than being a full 16 random bytes. The XSMP magic cookies do
not show such oddity:
> $ iceauth -f /run/user/1000/iceauth_pnzFrq list
> ICE "" local/Crushinator:@/tmp/.ICE-unix/4318 MIT-MAGIC-COOKIE-1
> 964a27f40bd66d7e0000000000000000
> XSMP "" local/Crushinator:@/tmp/.ICE-unix/4318 MIT-MAGIC-COOKIE-1
> 74e21845e90e6991e4a896578b14aa16
> ICE "" unix/Crushinator:/tmp/.ICE-unix/4318 MIT-MAGIC-COOKIE-1
> 3c5396e1498e520f1c00000000000000
> XSMP "" unix/Crushinator:/tmp/.ICE-unix/4318 MIT-MAGIC-COOKIE-1
> 3c50437513b2ffbfa1c12051b2640c04
Maybe KSMServer is actually expecting magic cookies that haven't had their
trailing bytes zeroed out. It could be that there is a use-after-free bug when
the iceauth file is being written out during session startup. Perhaps the magic
cookie data bytes are getting trashed before they are encoded to hex and
written to the file.
Notably, KSMServer also fails to clear the padding bytes in the ICE protocol
messages it sends. That's bad for protocol extensibility.
--
You are receiving this mail because:
You are watching all bug changes.
