standalone arts and mcop authentication
kstef at mtppi.org
Thu Oct 23 18:08:13 BST 2003
I'm attempting to use the standalone arts and artsd's network transparency to
handle sound from a server (kde is running on the server) on a diskless
workstation. It works fine with no authentication, but I think there's a
fundamental problem in the mcop authentication protocol when artsd and, say,
artsdsp are running on different computers.
From the documentation, the ServerHello includes the random cookie that is to
be mangled with the secret cookie to make an md5 hash. The client does this
and sends it back to authenticate - proving it has the secret cookie. Then
the server sends back a response that includes the 'hints' about what
GlobalComm mechanism to use.
In the Dispatcher, the connectUrl call causes the authentication exchange to
occur before the TmpGlobalComm or X11GlobalComm has been selected or
initialized - so there's no secret cookie yet. The mangling fails on an
assertion that the cookie has been initialized (md5_init).
To see this quickly, look in dispatcher.cc, where the connectUrl preceeds the
//MD5-Auth initialization section. This problem only occurs when ARTS_SERVER
One relatively easy fix would be to create an AuthDenied message that still
had the hints attached. The client could connect, fail to authenticate
correctly, but still get the hint back to use, for instance X11GlobalComm, to
find the secret-cookie. Any down side to this?
What I've done is just delay connecting at all until after the mcoprc file is
used to find the GlobalComm or TmpGlobalComm is initialized. The hints are
ignored. This solution could also use the GlobalComm get() to also figure out
the ARTS_SERVER instead of the environment variable. That makes it easy to
tie the sound output to the X server that's managing the relevant window.
If it has a reasonable chance of getting into future releases, I'll be glad to
do some coding on this. Please cc me on any replies.
More information about the kde-multimedia