Re: Re: [SLE] Invalid MIT-MAGIC-COOKIE-1 key
Actually.... Thats the way I have always had to do it....Why it happens that I can only guess at a security feature (I am taking a guess that it maybe to do with the video group 0660 and maybe not letting anyone outside of it attaching to the X process). I have little idea what has changed in your case...Did you run any updates? Its a security mechanism, do this in a in your terminal screen man xhost. Try my suggestion as I get the same as you do when I do not do the xhost command. Matt On Thu, 1 Feb 2001, Marcel Broekman wrote:
Hi Matthew,
I think you didn't understand my question (thanks all the same), so let me clarify this: I log in as a normal user and then start X. In X i open a terminal window where i su to root. After that i try to start a X-app (in the given example tkdesk and kpackage). That's when these error messages appear.This has never been a problem and it shouldn't to my knowledge. I just don't know where to begin to look to solve this problem. So i would be very greatful if you, or anyone else for that matter, could head me in the right direction, give me a few pointers. The strange thing is when i'm in KDE and start Konquerer filemanager in "superuser mode" and just click on the icons of the same apps they DO start! Funny stuff uh? (And pretty annoying too!)
mazzel, Marcel.
�Just a couple of quick questions (I should be in bed, but cannot get �away from Thinkgeek).
�Do you log in a user on the system? If so, are you running a program �via root through a terminal in your X sessions? If you are trying to �run a program via root then you need to do this as the user who �started the X sessions:
�xhost +localhost
�Then you can go in as root and eun your
On Thursday 01 February 2001 06:57, Matthew wrote: program.
�Hope that helps,
�Matt
�However,m if you are not sure what is
happening, then it seems like a
�program is trying to run as a root process, but needs to connect to �you
�On Thursday 01 February 2001 01:53 am, Marcel Broekman wrote: �> Hi all, �> �> The last few days i'm getting these error �> messages when i su to root and trying to execute �> things: �> �> marcelbr@susebox:~ > su �> Password: �> root@susebox:/home/marcelbr > tkdesk �> Xlib: connection to ":0.0" refused by server �> Xlib: Invalid MIT-MAGIC-COOKIE-1 key �> Application initialization failed: couldn't �> connect to display ":0" �> Error in startup script: invalid command name �> "wm" �> � � while executing �> "wm withdraw ." �> � � (file "/usr/X11R6/bin/tkdesk" line 41) �> root@susebox:/home/marcelbr > cd /opt/kde2/bin �> root@susebox:/opt/kde2/bin > ./kpackage �> Xlib: connection to ":0.0" refused by server �> Xlib: Invalid MIT-MAGIC-COOKIE-1 key �> kpackage: cannot connect to X server :0 �> root@susebox:/opt/kde2/bin > �> �> Can anyone tell me what these messages mean and �> how to get rid of them? �> �> TIA! �> �> mazzel, Marcel �>
Get your Free E-mail at http://thepenguin.zzn.com ____________________________________________________________ Get your own FREE Web and POP E-mail Service in 14 languages at http://www.zzn.com.
Actually....
Thats the way I have always had to do it....Why it happens that I can only guess at a security feature (I am taking a guess that it maybe to do with the video group 0660 and maybe not letting anyone outside of it attaching to the X process). I have little idea what has changed in your case...Did you run any updates? Its a security mechanism, do this in a in your terminal screen man xhost.
Try my suggestion as I get the same as you do when I do not do the xhost command.
<snip>
Do you log in a user on the system? If so, are you running a program via root through a terminal in your X sessions? If you are trying to run a program via root then you need to do this as the user who started the X sessions:
xhost +localhost
Then you can go in as root and eun your program.
This also happened to me. One of the IT support folk at work showed me how to get round it using basically the same fix as suggested. The only difference was in a konsole that was _not root_ I had to type: prompt> export DISPLAY=<IP address of machine or machine name>:0 prompt> xhost +localhost for this to work. Hope this helps, but please ignore if of no use as I am complete novice. Mark
Mark you are right :-). But if you are already in a X session and have a terminal up you should not need the export part, but the mileage may vary. Were you by any chance using the X session from a remote server? Maybe I should try that across the 'Net hehe... Matt On Thu, 1 Feb 2001, Mark Daglish wrote:
Actually....
Thats the way I have always had to do it....Why it happens that I can only guess at a security feature (I am taking a guess that it maybe to do with the video group 0660 and maybe not letting anyone outside of it attaching to the X process). I have little idea what has changed in your case...Did you run any updates? Its a security mechanism, do this in a in your terminal screen man xhost.
Try my suggestion as I get the same as you do when I do not do the xhost command.
<snip>
Do you log in a user on the system? If so, are you running a program via root through a terminal in your X sessions? If you are trying to run a program via root then you need to do this as the user who started the X sessions:
xhost +localhost
Then you can go in as root and eun your program.
This also happened to me. One of the IT support folk at work showed me how to get round it using basically the same fix as suggested. The only difference was in a konsole that was _not root_ I had to type:
prompt> export DISPLAY=<IP address of machine or machine name>:0 prompt> xhost +localhost
for this to work.
Hope this helps, but please ignore if of no use as I am complete novice.
Mark
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually.... :-) Using xhost is way way wrong. The correct way of doing things is: On your local machine do xauth list mymachine.mydomain.com:0.0 and you get a reply: mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1 37cb47264b485cd2e24ef9421def2a83 Then, on your remote machine do: xauth add mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1 37cb47264b485cd2e24ef9421def2a83 That's all. Your key shouldn't change that often, but when it does, just issue on the remote machine: xauth remove mymachine.mydomain.com:0 before you add the new key. Happy remote X-ing :-) - -tosi Þann fimmtudagur 01 febrúar 2001 21:29 skrifaðir þú:
Actually....
Thats the way I have always had to do it....Why it happens that I can only guess at a security feature (I am taking a guess that it maybe to
do
with the video group 0660 and maybe not letting anyone outside of it attaching to the X process). I have little idea what has changed in your case...Did you run any updates? Its a security mechanism, do this in a in your terminal screen man xhost.
Try my suggestion as I get the same as you do when I do not do the xhost command.
<snip>
Do you log in a user on the system? If so, are
you running a program
via root through a terminal in your X sessions?
If you are trying to
run a program via root then you need to do this
as the user who
started the X sessions:
xhost +localhost
Then you can go in as root and eun your
program.
This also happened to me. One of the IT support folk at work showed me how to get round it using basically the same fix as suggested. The only difference was in a konsole that was _not root_ I had to type:
prompt> export DISPLAY=<IP address of machine or machine name>:0 prompt> xhost +localhost
for this to work.
Hope this helps, but please ignore if of no use as I am complete novice.
Mark
- -- ______ /---------------------------------------\ \ | Þór Sigurðsson | Tor Sigurdsson | t | | Netmaður | Network Specialist | o | |-----------------------------------------| s | | tosi@rhi.hi.is | i | \---------------------------------------/_____/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e-SuSE (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6eeU06mRH+PEpr2YRApEqAKCSQyZ48pty9NlCpgG2blU/5bccuwCeIwbP 9jgIHUbkaup5jokB6DaQeMM= =WaMN -----END PGP SIGNATURE-----
Tor,
Actually.... :-)
Using xhost is way way wrong.
The correct way of doing things is:
On your local machine do
xauth list mymachine.mydomain.com:0.0
and you get a reply:
mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1 37cb47264b485cd2e24ef9421def2a83
Then, on your remote machine do:
xauth add mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1 37cb47264b485cd2e24ef9421def2a83
Thanks for putting us right, but... Actually ;-) This is what I do over the internet from machine to machine with ssh. If I can't get that to work (e.g. on one of the WinNT machines) then I use an xhost file. Not as secure I know but better than I was originally told to do by a colleague ("just do xhost + and it'll work). However, is the security thing an issue if xhost is only used for localhost? Mind you, for some reason that has now stopped working for me! Here is the scenario in a konsole window when logged on as any user: su - kwrite textfile& error message -> "kwrite: cannot connect to X server" even after doing the xhost + localhost thing. Suggestions? Many thanks, Mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Þann fimmtudagur 01 febrúar 2001 23:43 skrifaðir þú:
Tor,
Actually.... :-)
Using xhost is way way wrong.
The correct way of doing things is:
On your local machine do
xauth list mymachine.mydomain.com:0.0
and you get a reply:
mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1
37cb47264b485cd2e24ef9421def2a83
Then, on your remote machine do:
xauth add mymachine.mydomain.com:0 MIT-MAGIC-COOKIE-1
37cb47264b485cd2e24ef9421def2a83
Thanks for putting us right, but...
Actually ;-) This is what I do over the internet from machine to machine with ssh. If I can't get that to work (e.g. on one of the WinNT machines) then I use an xhost file. Not as secure I know but better than I was originally told to do by a colleague ("just do xhost + and it'll work).
Tell your colleague ignorance is bliss ;-)
However, is the security thing an issue if xhost is only used for localhost?
It is a security issue if it is a multi-user machine. There exist several applications to 'listen' to the chatter of X, and they catch the keypresses themselves, so they could catch your passwords, f.ex.
Mind you, for some reason that has now stopped working for me!
Here is the scenario in a konsole window when logged on as any user: su - kwrite textfile& error message -> "kwrite: cannot connect to X server"
even after doing the xhost + localhost thing.
Suggestions?
Many thanks,
Mark
Yup, Doing "su -" unsets your $DISPLAY. But "su" without the dash keeps all your environment variables, including $DISPLAY. su - export DISPLAY=[hostname]:0.0 kwrite /where/ever/textfile & or su kwrite /where/ever/textfile & :-) - -tosi - -- ______ /---------------------------------------\ \ | Þór Sigurðsson | Tor Sigurdsson | t | | Netmaður | Network Specialist | o | |-----------------------------------------| s | | tosi@rhi.hi.is | i | \---------------------------------------/_____/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e-SuSE (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6efvx6mRH+PEpr2YRAqFRAJ95xsfJj9cicFIOJHLpohwdpqxQ2wCgmjs7 mG39LiKGfEkXTIxYVvfcYwQ= =FUgi -----END PGP SIGNATURE-----
participants (3)
-
Mark Daglish -
Matthew -
Tor Sigurdsson