[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#251037: Strange xdmcp behavior, maybe a trojan horse?

On Sun, May 30, 2004 at 01:00:23AM +0200, Bartłomiej Ochman wrote:
> First thing first, in my opinion xdm works perfectly well in all those 
> situations. I think I understand now *why* it behaves this way. And what's 
> worst, it can be assumed as the right behavior. :-(

Hmmm.  :(

> So Xserver takes all the local IPs and sends them to a remote xdm process, 
> allowing him to choose the best. When it's in the same subnet, it will 
> choose local address (and that's why it worked for me within the same 
> subnet), but what when all IPs are non-local? It will take the first one 
> and will try to connect to it.
> Everything is OK according to RFCs. But on the other hand, loopback is only 
> a local interface, which never sends packets to a network. So in my 
> opinion, Xserver should never advertise its loopbacks. As far as I checked, 
> it doesn't send, except the situation when connecting to it 
> explicitely. I think it should never send *any* IP assigned to a loopback 
> [sub]interface(s). Unfortunately, I'm not sure there's easy way to check, 
> if an address is assigned to a loopback.

Are there even C library funtions that expose this information?

If not, I guess the only solutions are:

1) identify IP addresses associated with the loopback interface in one
   of xdm's config files (MAJORLY GROSS, one more thing to update when
   you reconfigure your network devices)
2) Hack up xdm to include Linux-specific code that queries /proc or
   someplace to find this information.  Also majorly gross.

> Sending loopback would make sense only in a situation, when the Xserver is 
> running on a multihomed box, with 2 (or more) interfaces which are 
> available through different paths. But who runs Xserver on a BGP router? ;-)
> I guess, that a scenario in #4757 was as follow:
> First interface up was eth0, possibly with a private IP. Second interface 
> up was ppp0 (so Xserver advertised private IP as the first one, and public 
> as the second). It caused remote xdm connects to an unavailable IP.
> Would configuring interfaces in some explicit order solve my (and all 
> other) problems? I'll try this next week.

Okay.  I can't do anything about this at present but I will await your

Thank you very much for researching this.

G. Branden Robinson                |      If you don't think for yourself,
Debian GNU/Linux                   |      others will think for you -- to
branden@debian.org                 |      their advantage.
http://people.debian.org/~branden/ |      -- Harold Gordon

Attachment: signature.asc
Description: Digital signature

Reply to: