Bug 8 - XFree86 apparently sets xhost to ill inital values
Summary: XFree86 apparently sets xhost to ill inital values
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 5.2
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1998-11-09 11:52 UTC by nils
Modified: 2016-01-19 00:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-19 00:10:27 UTC
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.