Bug 8

Summary: XFree86 apparently sets xhost to ill inital values
Product: [Retired] Red Hat Linux Reporter: nils
Component: XFree86Assignee: David Lawrence <dkl>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: 5.2CC: nils
Target Milestone: ---Keywords: Reopened, Security
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-19 00:10:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description nils 1998-11-09 11:52:56 UTC
Recently I got a complaint from one of our users that other
people could start X-programs on his machine, when they
logged into it and set their display appropriately.

I found that the xhost values were set to those values
regardless of the user:


Removing the offending lines (read: all) with
'xhost -LOCAL:', 'xhost -INET:<hostname>',
'xhost -<hostname>' or similar didn't work, only
the order of the lines changed.

If I added a host to the list, I could remove it, too, but
trying to remove the local host entries just failed.

I investigated a bit further and looked if there were xhost
lines in the start scripts (both of xdm and xinit), but
didn't find any.

I launched XF86_SVGA (as root) from a virtual console on a
different display (:1), ran xhost and got the same output,
so this is not a bug in Xwrapper.

This bug could be verified against XF86- and -18.
Thinking of xkey or similar 'tools' which can snoop X-events
or xwd/xwud and xwpick which can sniff screen contents this
is to be considered as a security breach.

Comment 1 nils 1998-11-10 02:48:59 UTC
I checked for this behaviour on my home machine and could not verify it. The
machines here and mine are very similar (core RH5.2, plus additional packages,
anything X related is (to my knowledge, I'll check this when I'm at home again)
stock RH, as well as glibc) -- except the kernel. Here we run the 2.0.36pre from
5.2 (production machines) and at home I run 2.1.12X.

Comment 2 nils 1998-11-12 03:20:59 UTC
Digged a little further on my home machine ... The symptoms only don't show,
when I log in via xdm. The console login / XF86_SVGA scenario behaves exactly
the same as on our machines here. If you can reproduce this bug, feel free
to contact me with any questions you may have.


Comment 3 David Lawrence 1998-11-13 16:52:59 UTC
This is the understood behaviour of X on any linux system.  It is not
a bug per se.  It is the way that xhost authorization works, as
opposed to xauth authorization, which is what xdm uses.

See the man pages for X and xdm for more information.

Comment 4 Fedora Update System 2015-11-10 15:56:26 UTC
atomic-1.6-3.git8a66e29.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-9c45b05861

Comment 5 Fedora Update System 2015-11-11 02:23:01 UTC
atomic-1.6-3.git8a66e29.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update atomic'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-9c45b05861

Comment 6 Fedora Update System 2015-11-11 16:08:15 UTC
atomic-1.6-4.git8a66e29.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cb8a57cc66