Re: XFree86 4.2 bug in Debian Testing
On Fri, Nov 08, 2002 at 05:28:52PM +0100, Ivan Brezina wrote: On Fri, 8 Nov 2002, Joseph Pingenot wrote: From Norbert Preining on Friday, 08 November, 2002: I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Probably the easiest way to do this is, instead of using su/sudo, run ssh -X localhost. It'll tunnel your X apps back over the tunnel. Not as efficient, but it'll solve permissions problems. Or, you can have root snag your user .Xauthority file to steal the user cookies. Then you can just set display:0.0. Another possibility is: su -c vim-gtk you can also use xhost +username for allowing users to connect to our Xserver. But this does not work for me on Debian. xhost is _host_ based access control, so of course xhost +username doesn't work! Debian by default starts X servers with -nolisten tcp, so doing xhost + (to allow all connections) is the same as xhost +localhost, and is ok if (and _only_ if) there are no local users you don't absolutely trust (including trusting them not to get their accounts cracked with bad passwords). I emphatically do not recommend using ssh running X stuff as root. That is _huge_ overhead compared to unix sockets and shared memory! (If it's working fine for you, then whatever, do what's easiest for you, but if you're going to go to the trouble of learning how to jump through a hoop to get X working, pick the right hoop!) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
On Fri, Nov 08, 2002 at 05:28:52PM +0100, Ivan Brezina wrote: On Fri, 8 Nov 2002, Joseph Pingenot wrote: From Norbert Preining on Friday, 08 November, 2002: I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Probably the easiest way to do this is, instead of using su/sudo, run ssh -X localhost. It'll tunnel your X apps back over the tunnel. Not as efficient, but it'll solve permissions problems. Or, you can have root snag your user .Xauthority file to steal the user cookies. Then you can just set display:0.0. Another possibility is: su -c vim-gtk you can also use xhost +username for allowing users to connect to our Xserver. But this does not work for me on Debian. xhost is _host_ based access control, so of course xhost +username doesn't work! Debian by default starts X servers with -nolisten tcp, so doing xhost + (to allow all connections) is the same as xhost +localhost, and is ok if (and _only_ if) there are no local users you don't absolutely trust (including trusting them not to get their accounts cracked with bad passwords). I emphatically do not recommend using ssh running X stuff as root. That is _huge_ overhead compared to unix sockets and shared memory! (If it's working fine for you, then whatever, do what's easiest for you, but if you're going to go to the trouble of learning how to jump through a hoop to get X working, pick the right hoop!) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC
Re: XFree86 4.2 bug in Debian Testing
* David Stanaway [EMAIL PROTECTED] [20021110 14:19]: On Fri, 2002-11-08 at 11:42, Joseph Pingenot wrote: xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. Try.. xhost + 'local:*' not much better. this way, you 'only' give local users access to your X-session to open (transparent, event catching, screenshoting) windows and the like, not the hole world .. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
* David Stanaway [EMAIL PROTECTED] [20021110 14:19]: On Fri, 2002-11-08 at 11:42, Joseph Pingenot wrote: xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. Try.. xhost + 'local:*' not much better. this way, you 'only' give local users access to your X-session to open (transparent, event catching, screenshoting) windows and the like, not the hole world .. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it ..
Re: XFree86 4.2 bug in Debian Testing
I am using woody + testing + some unstable: in xterm/gnome-terminal usually I do (as normal user) xhost + This disables access control in the X server. This is, almost always, a very bad idea. Indeed. Therefore I use mfluch@seneca:~$ su Password: root@seneca:/home/mfluch export XAUTHORITY=/home/mfluch/.Xauthority root@seneca:/home/mfluch ...and then every X application works just as before as the normal user. - Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
Quoting Martin Fluch ([EMAIL PROTECTED]): Indeed. Therefore I use mfluch@seneca:~$ su Password: root@seneca:/home/mfluch export XAUTHORITY=/home/mfluch/.Xauthority root@seneca:/home/mfluch ...and then every X application works just as before as the normal user. It's a little simpler to do: $ ssh -X root@localhost -- Cheers, Right to keep and bear Rick Moen Haiku shall not be abridged [EMAIL PROTECTED] Or denied. So there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
On Sat, 9 Nov 2002, Rick Moen wrote: mfluch@seneca:~$ su Password: root@seneca:/home/mfluch export XAUTHORITY=/home/mfluch/.Xauthority root@seneca:/home/mfluch ...and then every X application works just as before as the normal user. It's a little simpler to do: $ ssh -X root@localhost Even easier: the following lines in the /root/.bashrc do the same trick: if [ ! $LOGNAME = root ]; then export XAUTHORITY=/home/$LOGNAME/.Xauthority fi And then su works without any problem (and computational overhead as the ssh sollution). Cheers, - Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
su and x (was Re: XFree86 4.2 bug in Debian Testing)
On Sat, 9 Nov 2002, Jörg Schütter wrote: On Sat, 9 Nov 2002 13:36:25 +0200 (EET) Martin Fluch [EMAIL PROTECTED] wrote: On Sat, 9 Nov 2002, Rick Moen wrote: It's a little simpler to do: $ ssh -X root@localhost Even easier: the following lines in the /root/.bashrc do the same trick: if [ ! $LOGNAME = root ]; then export XAUTHORITY=/home/$LOGNAME/.Xauthority fi This solution doesn't work with su - And then su works without any problem (and computational overhead as the ssh sollution). You can decrease the overhead with ssh -c des -X root@localhost And for what reason use ssh when the application can connect directly to X. Why insert ssh inbetween? Cheers, - Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su and x (was Re: XFree86 4.2 bug in Debian Testing)
Try http://fgouget.free.fr/sux/sux-readme.shtml chj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
Quoting Martin Fluch ([EMAIL PROTECTED]): Indeed. Therefore I use [EMAIL PROTECTED]:~$ su Password: [EMAIL PROTECTED]:/home/mfluch export XAUTHORITY=/home/mfluch/.Xauthority [EMAIL PROTECTED]:/home/mfluch ...and then every X application works just as before as the normal user. It's a little simpler to do: $ ssh -X [EMAIL PROTECTED] -- Cheers, Right to keep and bear Rick Moen Haiku shall not be abridged [EMAIL PROTECTED] Or denied. So there.
Re: XFree86 4.2 bug in Debian Testing
On Sat, 9 Nov 2002, Rick Moen wrote: [EMAIL PROTECTED]:~$ su Password: [EMAIL PROTECTED]:/home/mfluch export XAUTHORITY=/home/mfluch/.Xauthority [EMAIL PROTECTED]:/home/mfluch ...and then every X application works just as before as the normal user. It's a little simpler to do: $ ssh -X [EMAIL PROTECTED] Even easier: the following lines in the /root/.bashrc do the same trick: if [ ! $LOGNAME = root ]; then export XAUTHORITY=/home/$LOGNAME/.Xauthority fi And then su works without any problem (and computational overhead as the ssh sollution). Cheers, - Martin
Re: XFree86 4.2 bug in Debian Testing
On Sat, 9 Nov 2002 13:36:25 +0200 (EET) Martin Fluch [EMAIL PROTECTED] wrote: On Sat, 9 Nov 2002, Rick Moen wrote: It's a little simpler to do: $ ssh -X [EMAIL PROTECTED] Even easier: the following lines in the /root/.bashrc do the same trick: if [ ! $LOGNAME = root ]; then export XAUTHORITY=/home/$LOGNAME/.Xauthority fi This solution doesn't work with su - And then su works without any problem (and computational overhead as the ssh sollution). You can decrease the overhead with ssh -c des -X [EMAIL PROTECTED] Gruß Jörg -- http://www.lug-untermain.de/ - http://mypenguin.bei.t-online.de/ Dipl.-Ing. Jörg Schütter [EMAIL PROTECTED]
su and x (was Re: XFree86 4.2 bug in Debian Testing)
On Sat, 9 Nov 2002, Jörg Schütter wrote: On Sat, 9 Nov 2002 13:36:25 +0200 (EET) Martin Fluch [EMAIL PROTECTED] wrote: On Sat, 9 Nov 2002, Rick Moen wrote: It's a little simpler to do: $ ssh -X [EMAIL PROTECTED] Even easier: the following lines in the /root/.bashrc do the same trick: if [ ! $LOGNAME = root ]; then export XAUTHORITY=/home/$LOGNAME/.Xauthority fi This solution doesn't work with su - And then su works without any problem (and computational overhead as the ssh sollution). You can decrease the overhead with ssh -c des -X [EMAIL PROTECTED] And for what reason use ssh when the application can connect directly to X. Why insert ssh inbetween? Cheers, - Martin
Re: su and x (was Re: XFree86 4.2 bug in Debian Testing)
Try http://fgouget.free.fr/sux/sux-readme.shtml chj
Re: XFree86 4.2 bug in Debian Testing
No, but I have noticed when i open an xterm, su to root and run vi(vim-gtk), whenever I quit vi, i get this. Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server myhost:# Probably not related, but it seems weird to me, cause it only does this in vi, and vi shouldn't be connecting to the xterminal, or it it? On Thu, 2002-11-07 at 19:25, Time wrote: I'm not sure if this is just me, but when I shutdown X properly and then `su -` in that terminal I get flooded with Password: prompts. Has anyone else seen this? -- Regards, Time 13 \ 9 . 3 clockbot.net / 6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
On Fre, 08 Nov 2002, Steve Johnson wrote: No, but I have noticed when i open an xterm, su to root and run vi(vim-gtk), whenever I quit vi, i get this. Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server myhost:# Probably not related, but it seems weird to me, cause it only does this in vi, and vi shouldn't be connecting to the xterminal, or it it? I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HOGGESTON (n.) The action of overshaking a pair of dice in a cup in the mistaken belief that this will affect the eventual outcome in your favour and not irritate everyone else. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
This one time, at band camp, Steve Johnson said: No, but I have noticed when i open an xterm, su to root and run vi(vim-gtk), whenever I quit vi, i get this. Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server myhost:# Probably not related, but it seems weird to me, cause it only does this in vi, and vi shouldn't be connecting to the xterminal, or it it? Well, vim-gtk does. It's an X app (hence the -gtk). X in debian by default won't allow this. You can either use sudo, or set up X to allow it. Steve -- Everything should be made as simple as possible, but not simpler. -- Albert Einstein msg07636/pgp0.pgp Description: PGP signature
Re: XFree86 4.2 bug in Debian Testing
From Norbert Preining on Friday, 08 November, 2002: I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Probably the easiest way to do this is, instead of using su/sudo, run ssh -X localhost. It'll tunnel your X apps back over the tunnel. Not as efficient, but it'll solve permissions problems. Or, you can have root snag your user .Xauthority file to steal the user cookies. Then you can just set display:0.0. -Joseph -- [EMAIL PROTECTED] As far as Microsoft, we will never take a company lightly that can put $3bn in cash in the bank every quarter. --Mark Tolliver, Sun Microsystems -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
On Fri, 8 Nov 2002, Joseph Pingenot wrote: From Norbert Preining on Friday, 08 November, 2002: I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Probably the easiest way to do this is, instead of using su/sudo, run ssh -X localhost. It'll tunnel your X apps back over the tunnel. Not as efficient, but it'll solve permissions problems. Or, you can have root snag your user .Xauthority file to steal the user cookies. Then you can just set display:0.0. Another possibility is: su -c vim-gtk you can also use xhost +username for allowing users to connect to our Xserver. But this does not work for me on Debian. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
From Ivan Brezina on Friday, 08 November, 2002: Another possibility is: su -c vim-gtk you can also use xhost +username for allowing users to connect to our Xserver. But this does not work for me on Debian. xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. -Joseph -- [EMAIL PROTECTED] As far as Microsoft, we will never take a company lightly that can put $3bn in cash in the bank every quarter. --Mark Tolliver, Sun Microsystems -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. I am using woody + testing + some unstable: in xterm/gnome-terminal usually I do (as normal user) xhost + su - as root export DISPLAY=:0.0 and all X programs works signature.asc Description: This is a digitally signed message part
Re: XFree86 4.2 bug in Debian Testing
On Fri, 2002-11-08 at 11:42, Joseph Pingenot wrote: xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. Try.. xhost + 'local:*' -- David Stanaway -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
Indeed. My mistake. I just verified that X wasn't listening in to tcp/6000, xhost +'ed, and su -'ed, setup the display variable, and it worked. NM. I'm wrong. Seems something on this guy's end is borken. -Joseph -- [EMAIL PROTECTED] As far as Microsoft, we will never take a company lightly that can put $3bn in cash in the bank every quarter. --Mark Tolliver, Sun Microsystems -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
On Fri, Nov 08, 2002 at 10:53:10AM -0800, Yogesh Sharma wrote: xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. I am using woody + testing + some unstable: in xterm/gnome-terminal usually I do (as normal user) xhost + This disables access control in the X server. This is, almost always, a very bad idea. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2 bug in Debian Testing
On Fre, 08 Nov 2002, Steve Johnson wrote: No, but I have noticed when i open an xterm, su to root and run vi(vim-gtk), whenever I quit vi, i get this. Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server myhost:# Probably not related, but it seems weird to me, cause it only does this in vi, and vi shouldn't be connecting to the xterminal, or it it? I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HOGGESTON (n.) The action of overshaking a pair of dice in a cup in the mistaken belief that this will affect the eventual outcome in your favour and not irritate everyone else. --- Douglas Adams, The Meaning of Liff
Re: XFree86 4.2 bug in Debian Testing
This one time, at band camp, Steve Johnson said: No, but I have noticed when i open an xterm, su to root and run vi(vim-gtk), whenever I quit vi, i get this. Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server myhost:# Probably not related, but it seems weird to me, cause it only does this in vi, and vi shouldn't be connecting to the xterminal, or it it? Well, vim-gtk does. It's an X app (hence the -gtk). X in debian by default won't allow this. You can either use sudo, or set up X to allow it. Steve -- Everything should be made as simple as possible, but not simpler. -- Albert Einstein pgpvJZm20pu2B.pgp Description: PGP signature
Re: XFree86 4.2 bug in Debian Testing
From Norbert Preining on Friday, 08 November, 2002: I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Probably the easiest way to do this is, instead of using su/sudo, run ssh -X localhost. It'll tunnel your X apps back over the tunnel. Not as efficient, but it'll solve permissions problems. Or, you can have root snag your user .Xauthority file to steal the user cookies. Then you can just set display:0.0. -Joseph -- [EMAIL PROTECTED] As far as Microsoft, we will never take a company lightly that can put $3bn in cash in the bank every quarter. --Mark Tolliver, Sun Microsystems
Re: XFree86 4.2 bug in Debian Testing
On Fri, 8 Nov 2002, Joseph Pingenot wrote: From Norbert Preining on Friday, 08 November, 2002: I think that vim-gtk tries to open a window, recognizes that this doesn't work (authorization) and starts normal text mode vi. Probably the easiest way to do this is, instead of using su/sudo, run ssh -X localhost. It'll tunnel your X apps back over the tunnel. Not as efficient, but it'll solve permissions problems. Or, you can have root snag your user .Xauthority file to steal the user cookies. Then you can just set display:0.0. Another possibility is: su -c vim-gtk you can also use xhost +username for allowing users to connect to our Xserver. But this does not work for me on Debian. Ivan
Re: XFree86 4.2 bug in Debian Testing
xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. I am using woody + testing + some unstable: in xterm/gnome-terminal usually I do (as normal user) xhost + su - as root export DISPLAY=:0.0 and all X programs works signature.asc Description: This is a digitally signed message part
Re: XFree86 4.2 bug in Debian Testing
On Fri, 2002-11-08 at 11:42, Joseph Pingenot wrote: xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. Try.. xhost + 'local:*' -- David Stanaway
Re: XFree86 4.2 bug in Debian Testing
Indeed. My mistake. I just verified that X wasn't listening in to tcp/6000, xhost +'ed, and su -'ed, setup the display variable, and it worked. NM. I'm wrong. Seems something on this guy's end is borken. -Joseph -- [EMAIL PROTECTED] As far as Microsoft, we will never take a company lightly that can put $3bn in cash in the bank every quarter. --Mark Tolliver, Sun Microsystems
Re: XFree86 4.2 bug in Debian Testing
On Fri, Nov 08, 2002 at 10:53:10AM -0800, Yogesh Sharma wrote: xhost is for working with connections coming over tcp. :0.0 uses a named socket (/tmp/Xsomething), and Debian's X servers don't listen in on a tcp socket by default (security. No chance of someone sniffing your password if nobody can connect remotely!). Thus, xhost won't work. I am using woody + testing + some unstable: in xterm/gnome-terminal usually I do (as normal user) xhost + This disables access control in the X server. This is, almost always, a very bad idea. -- - mdz
