GNOME Bugzilla – Bug 164628
XDMCP violation
Last modified: 2010-06-16 19:54:09 UTC
According to the XDMCP specification (which is available in the xc/doc/hardcopy/XDMCP/ directory of the X server source) it is legal for a DMCP client to request display services for a display on a *different* address than the address of the client itself. The soon-to-be-attached patch fixes this problem, but only in the IPv4 code path of gdm, ie. ENABLE_IPV6 not-defined. I haven't fixed it in the IPV6 branch, because I have no way of testing it and because I am not all that familiar with the IPv6 API.
Created attachment 36255 [details] [review] patch
This patch should also be made to work with IPv6. I've cc:ed Archana and Vijay from Wipro who have worked on making gdm2 support IPv6 in the past. Archana & Vijay, could you help to enhance this patch so it also works with IPv6?
Sure Brian, I will look into this.
Created attachment 46394 [details] [review] Proposed patch
Attached is the patch which includes changes for IPv4 and IPv6 both. We need to test it. Brian, Soren: Please let know the test cases
I don't have any testcases other than my old IP4 tests, but I did make a note that to fully test this you need to cover at least these cases ip6 talking to ip6 about ip4 display ip4 talking to ip4 about ip4 display ip6 talking to ip6 about ip6 display ip4 talking to ip4 about ip6 display
Soren, could you share your IPv4 test case with Archana. I'm sure that will help him understand how to test the ipv6 code. I'm happy to put this patch into GDM2 once we have tested it.
Created attachment 46433 [details] The test case To actually compile this program, you need to have the library lac installed. A snapshot is available from http://www.daimi.au.dk/~sandmann/lac-0.6snap.tar.gz The test program itself takes two arguments, the hostname of a manager, ie. computer running gdm, and an X display, such as my-computer:0. The program will then attempt to contact gdm via DMCP and ask it to manage the display of my-computer:0. Without the patch, the testcase fails when "my-computer" is different from the system running the testcase.
Thanks Soren, I will test the patch and update early in the next week.
Soren, I tried to check the behaviour with IPv4 addresses (without patching gdm) so that I know what to expect from the IPv6 test cases. But I have some queries regarding this.. For IPv4 addresses: =================== a.) The test program should probably succeed when I run it like this: ./test-program 10.114.56.113 10.114.56.113:0.0 But it parses the display-id, then g_main_loop_run () starts and it waits there indefinetely. Is it expecting some input/trigger from the user at this point ? b.) When it fails for you, does it give some messages ? I ran it by giving a different ip address in the second argument like this: ./test-program 10.114.56.113 10.114.56.38:0.0 c.) Does it query gdm ? I enabled debugging in gdm and then ran the test program but gdm doesn't seem to be getting queried. (I dont see any debugging output from gdm) For IPv6 addresses: =================== a.) I have 0.6snap version of lac library. This doesn't seem to have support for IPv6 addresses. Is there anyother way that I can test the patch ?
(a) The test program doesn't use the glib main loop at all, so I am not sure what you mean by "g_main_loop_run () starts". If it is just waiting, it is most likely waiting for gdm to send the next step in the protocol. (b) No, when it fails, it simply doesn't manage the given display. Instead it tries to put up a box on the display running on the system that ran the testcase. (c) Yes, if yo run it as testcase <foo> <bar>:0 it will query a gdm running on foo, and ask it to manage a display running on bar:0 As I said, I don't have any IPv6 testcases because I don't have an IPv6 setup. So you'll need to come up with an IPv6 testcase yourself, possibly based on my IP4 based one.
Hi, What about this? I think that bug #385451 is related
Could you test the patch and see if it fixes the problem? This patch hasn't gone in, as you can see, because nobody has been able to verify that the patch actually works.
What about this bug? I didn't test the patch earlier and now the patch doesn't apply cleanly... :/
The XDMCP code has changed quite a bit, and this patch is rather old. Sorry about that. Note that the codebase in GDM 2.20 and 2.21 are quite different now since GDM 2.21 has been rewritten. If you want to try to get this patch working with the latest code, note that the code has moved into daemon/gdm-xdmcp-manager.c in 2.20 and into daemon/gdm-xdmcp-display-factory.c in 2.21. Note the code is similar, but variables have changed name and some of the IPv4/IPv6 ifdef's have been replaced with code that is a bit more generic and works with either. Before spending a bunch of time on this, it might be worth seeing if this patch actually works. It might be good to try and build an older version of GDM (where the patch applies cleanly) and see if applying the patch actually fixes your problem. I'd bet it would still probably apply cleanly with GDM 2.18.
The patch certainly works in the sense that we (Red Hat) is shipping it to customers with this particular problem. It doesn't work with IPv6 though - it simply doesn't address that.
The question in comment #13 has been answered in comment #16. I am thus reopening.
The lac library did have a bit of a problem when using numerical ip addresses that prevented the test program from working. I hacked in something like: @@ -414,7 +415,9 @@ lac_address_new_from_name_wait (const gchar *name, lac_address_new_lookup_all_from_name ( name, ghbn_callback, &ghbn_info); - g_main_loop_run (ghbn_info.loop); + if (ghbn_info.result == NULL && ghbn_info.err == NULL) { + g_main_loop_run (ghbn_info.loop); + } With that change the test program works fine and correctly with GDM in recent releases. Thanks.