networking arts outwith X

[Stefan Westerfeld]

   Hi!

On Sun, Jan 05, 2003 at 02:48:30PM +0100, Matthias Kretz wrote:
> On Saturday 04 January 2003 21:59, George Mochrie wrote:
> > I'm currently evaluating different ways of running X/KDE remotley on
> > low-spec PCs and I could do with some help. I don't want to eat up too much
> > network bandwidth and the spec of the xterms is an issue so I'm currently
> > thinking of VNC using svgalib clients. Would it be possible to run artsd on
> > the client and have all the groovy network transparency stuff without X?
> > Could I tunnel it over ssh (not sure if I really want to, but everything
> > else I need will be
> 
> One way it could work:
> Start artsd on the client with network transparency enabled (no need for 
> X11GlobalComm - you can use the default of TmpGlobalComm).
> It would make your life a lot easier if you tell artsd which port to use for 
> tcp communication else you'd need "somehow" find that port number later.
> 
> Then do the following on the application server:
> export ARTS_SERVER=<client's ip address or domain name>:<portnumber>
> This will tell all applications using the artsserver to connect to the remote 
> artsd.
> 
> Ah, I almost forgot: The apps need to authenticate with artsd. Either you 
> disable authentication (for testing) or you find a way to automatically make 
> it work [...]
> 
> BUT there's some code missing - not a lot 
> since I did some things already in kdenonbeta/arts/{jitterbuffer,branch} (but 
> this is currently only working with a running X server since the 
> authentication is done over X.

I've thought a lot over the authentication problem myself in the last time,
and even implemented another authentication scheme. But it seems that the new
one is too complex (it allows specifying a server to accept only certain
clients, and a client to connect only to certain servers), and not really
secure, as the problem is, that through cookie based authentication anyone
needs to know anyones cookie to successfully identify him, and can thus pretend
to be anyone as well.

If somebody is interested in looking at it, I can provide a patch.

Nevertheless, I think the current situation needs to be improved. The problem
is that with TmpGlobalComm the cookie is storied in /tmp. Thus, if you start
a server on one computer and a client on another the cookies will be different
(as they have different stuff in /tmp) and thus the authentication will fail
if you're using TmpGlobalComm. The same is true if you're trying to build a
connection between different users on the same system.

You can work around this (by doing cp ~/my-common-cookie /tmp/mcop-<username>/
secret-cookie) or similar. I think the most useful way to change this for the
next version of aRts (and thus, for KDE3.2) would be to use
~/.mcop/secret-cookie if it exists as new cookie, and write the cookie also
there.

While this means that on NFS mounted homes (which quite some people use), the
cookie will be automatically kept in sync, it also means that on NFS mounted
homes, it will be transferred as plain-text over the local network. There,
again, is a security vs. usability tradeoff to be made, but I think the new
way is better than the old (as the old is absolutely unusable).

The code for doing so should also be folded into CSL. Then, using the CSL
aRts driver (and compiling arts with --enable-csl) will allow cascading. Other
apps that can use CSL will also be able to do authenticated cascading, then,
which until now has not been possible due to the cookie problem.

Okay, thats just thoughts for now, any comments are welcome, and I hope to get
the time to do the implementation of these soonish.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-