This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
MIT-MAGIC-COOKIE-1 problem
- From: Peter Giorgilli <pgiorgilli at theage dot fairfax dot com dot au>
- To: cygwin xfree <cygwin-xfree at cygwin dot com>
- Date: Tue, 14 May 2002 17:26:48 +1000
- Subject: MIT-MAGIC-COOKIE-1 problem
- Organization: The Age
- Reply-to: pgiorgilli at theage dot fairfax dot com dot au
Hello all!
Firstly, thanks to everyone involved with cygwin/xfree for making such a
wonderful tool freely available.
By way of introduction, I'm currently investigating the feasibility of
using cygwin/xfree to run OpenOffice from a Linux server. In my work so
far, I've come across one problem that I wanted to share with the list
which involves security, or more to point, MIT-MAGIC-COOKIE-1-style
security. In our environment we require access to the local display both
locally and remotely. Currently, the only client we run locally is
"xwinclip" to enable clipboard interoperability. Otherwise, all client
applications (e.g., OpenOffice) run remotely.
This translates to 3 cookies:
1. local display (:0)
2. localhost (127.0.0.1:0)
3. network interface (for example, 192.168.192.1:0)
In summary, what I've found is if you specify the path to the
"XAUTHORITY" file on the command line in DOS-format (-auth
C:\TEMP\.Xauthority), then local applications can connect using any one
of the following display settings, and all 3 of the following commands
work.
xclock -display :0
xclock -display 127.0.0.1:0
xclock -display 192.168.192.1:0
However, if I try to access the same display remotely, I get the
following error message:
Xlib: connection to "192.168.192.1:0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: 192.168.192.1:0
Reversing the situation, if you specify the path to the "XAUTHORITY"
file on the command line in UNIX-format (-auth /tmp/.Xauthority, where
/tmp is mounted on C:\TEMP), then remote clients can access the display
remotely. However, local applications can now only access the display
via 192.168.192.1:0. Weird! There must be something that I'm missing.
Note, in both situations the X-authorization records were correctly
copied to the remote system. I visually checked as much using the
"xauth" command.
I don't think this is hard to re-produce so I'd be interested in what
others find. My guess is that the X server is somehow not consulting the
"XAUTHORITY" file when a connection attempt is made from either :0
(UNIX-domain socket) or 127.0.0.1:0 (localhost) but only when the path
to the "XAUTHORITY" file is specified in UNIX-format.
Regards
Peter G.
*********************************************************************************
This email and any files transmitted with it may be legally privileged
and confidential. If you are not the intended recipient of this email,
you must not disclose or use the information contained in it. If you
have received this email in error, please notify us by return email and
permanently delete the document.
*********************************************************************************