This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

MIT-MAGIC-COOKIE-1 problem


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.
*********************************************************************************


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]