Hi,
the whole point seems to be that your X is configured by default to use a security mechanism called MIT-MAGIC-COOKIE . BTW, sounds like a good idea, much better than the "xhost" mechanism which is fairly unsecure.
Basically, it works like that:
1. when you launch your X server it computes a "cookie" (long hex stream) to authenticate your session
2. whenever a program tries to connect to your X server, it has to send the appropriate cookie first to be able to connect, otherwise the connection will be refused.
The cookie is stored in the ~/.Xsession file , which explains why linking/copying .Xsession files from one home dir to another works.
This "hack" is indeed a bad idea, from a security point of view. You would not like to give all your credit card numbers to someone else if all he needs is one of them, would you? Because your .Xsession contains the cookie for _all_ your X connections, even on remote machines!
Thus the right way to do what you want seems to me to follow this path:
1. run 'xauth list' : this will display all your current X cookies (btw, there is no mechanism to assure they are still valid: every time you restart a X server it regenerates a new one)
2. su to the user you want to (root for example)
3. set your environment variable DISPLAY to point to your target X server.
In the case where you connect locally, it is true that using Unix sockets will be more efficient, so set you DISPLAY to "my.local.machine/unix:0" and not to "my.local.machine:0" .
4. run 'xauth add $DISPLAY . the_token_you_grabbed_at_first_step '
Note the "." . It is a shortcut for the magic word "MIT-MAGIC-COOKIE-1" and saves your keyboard types!
5. run whatever X program you want, it will connect to your X server seemlessly.
Last thing: if you really want to live in an unsecure but no-brainer-friendly environment, you would issue an "xhost +" before doing su, which allows every machine and every user on earth to connect to your X server without authentication.
Which is easier if you work on a stand-alone machine without connection to any network. But again, this is _bad_ habits.
HTH
Thierry
-----Original Message-----
From: John Bagdanoff [mailto:bagdanof@home.com]
Sent: Friday, July 14, 2000 11:14 AM
To: Debian User List
Subject: Re: display export??
On Thu, Jul 13, 2000 at 08:52:22PM -0400, Noah L. Meyerhans wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Fri, 14 Jul 2000, Ragga Muffin wrote:
>
> > > do I need to export DISPLAY localhost? Im not sure of the syntax...am I on the right track?
> >
> > Yes and no. What yuo need to do is temporarily permit x-connections from
> > your localhost if you want to start an x program with a different
> > user than the current session (in this case root)
> >
> > Simply execute 'xhost +localhost' before doing a su.
>
> I think that doing xhost local:root is better. There are 2 reasons for
> this:
> 1. You're specifying a user name, which gives added security if you've
> got a multi-user system.
>
> 2. You're specifying a local connection, not a connection that uses a
> network interface. The X server connections with use Unix sockets, not
> TCP sockets. This gives you less overhead since you don't have to send
> all your data through a TCP stack.
>
The solution I found awhile ago was to link /root/.Xauthority to
/home/<user>/.Xauthority
John
> noah
>
> _______________________________________________________
> | Web: http://web.morgul.net/~frodo/
> | PGP Public Key: http://web.morgul.net/~frodo/mail.html
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQCVAwUBOW5kTIdCcpBjGWoFAQGFjAP/V/dalkL6GK7O8Mwbgd//3GpLQLU7e5GG
> wPl9hHIZm8tjx1FOHlxtnpxHw8RREof1ttubhR1n2Rvs8UVXfHpqIf0V5nQf2FGA
> viuMT6NUtFfi2fcvq9607vc2nPPR8yqwe5aMFhVV3fj13PpIYRqxz0nnuH7NoU+F
> 3AN2DeTRBDo=
> =MEnf
> -----END PGP SIGNATURE-----
>
>
> --
> Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
>
--
************************
Using Linux
************************
--
Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null