Bug 8

Summary:	XFree86 apparently sets xhost to ill inital values
Product:	[Retired] Red Hat Linux	Reporter:	nils
Component:	XFree86	Assignee:	David Lawrence <dkl>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	5.2	CC:	nils
Target Milestone:	---	Keywords:	Reopened, Security
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
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:
Embargoed:

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:

--8<--
LOCAL:
INET:localhost
INET:<hostname>
INET:<hostname>
--8<--

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-3.3.2.3-25 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.

Nils

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