Bug 426517

Summary:	xhost -SI:localuser:tempuser fails to remove user from access list
Product:	[Fedora] Fedora	Reporter:	Dave Allan <redhat>
Component:	xorg-x11-server-utils	Assignee:	Adam Jackson <ajax>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	8	CC:	gentoo_eshoes, mcepl, pkay42, xgl-maint
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	f8Current	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-22 11:15:26 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 Dave Allan 2007-12-21 18:44:36 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/20071213 Fedora/2.0.0.10-3.fc8 Firefox/2.0.0.10

Description of problem:
I added a temporary user to the xhost access list with:

xhost +SI:localuser:tempuser

which worked properly and the tempuser was able to make connections to the X server.  I then tried to remove the user from the access list which failed:

[user@host ~]$ xhost -SI:localuser:tempuser
localuser:tempuser being removed from access control list
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  109 (X_ChangeHosts)
  Value in failed request:  0x12
  Serial number of failed request:  7
  Current serial number in output stream:  9
[user@host ~]$

and the tempuser is still able to access the X server.

Version-Release number of selected component (if applicable):
xorg-x11-server-utils-7.3-2.fc8

How reproducible:
Always


Steps to Reproduce:
1. start X & login as some user
2. execute:
xhost +SI:localuser:tempuser <-- where tempuser is an existing (non-root) account.  I did not test to see if superuser status affects the behavior; I assumee not.
3. verify that tempuser can connect to the X server
4. execute:
xhost -SI:localuser:tempuser
5. Look for the error message and confirm that tempuser can still connect to the X server.

Actual Results:
see Description.

Expected Results:
see Description.

Additional info:

Comment 1 Adam Jackson 2008-02-21 18:00:50 UTC

That's bizarre, it certainly works here:

atropine:~% xhost +si:localuser:root
localuser:root being added to access control list
atropine:~% xhost -si:localuser:root
localuser:root being removed from access control list

What does 'xhost' on its own report?  I imagine you're getting a hostname in the
access list that ends up not being valid when you want to modify the list.

Comment 2 Dave Allan 2008-02-21 18:11:18 UTC

That is pretty strange.  Today is the one day a week I'm away from that machine,
so I'll try it again tonight or tomorrow.  I wasn't trying to add a superuser,
though.  What happens if you create a temp user and add them to the list?

Comment 3 Dave Allan 2008-02-22 02:31:16 UTC

Huh...strange.  Now it's working.  I guess it can be resolved as NR.

Comment 4 Matěj Cepl 2008-02-22 11:15:26 UTC

Thanks for letting us know.

Comment 5 inactive 2020-01-24 04:59:20 UTC

For future reference that error happens when the user ("tempuser", above) doesn't exist.

$ xhost -SI:localuser:nonexitentuser
localuser:nonexitentuser being removed from access control list
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  109 (X_ChangeHosts)
  Value in failed request:  0x18
  Serial number of failed request:  7
  Current serial number in output stream:  9

$ sudo useradd nonexitentuser
[sudo] password for user: 

$ xhost -SI:localuser:nonexitentuser
localuser:nonexitentuser being removed from access control list

$ xhost -SI:localuser:nonexitentuser
localuser:nonexitentuser being removed from access control list

(it's the same for +SI)
$ xhost
access control enabled, only authorized clients can connect
SI:localuser:nonexitentuser
LOCAL:

Comment 6 Peter 2020-06-10 15:36:11 UTC

Can this be reopened as "xhost gives completely unhelpful error message when authorizing nonexistent users"?  Or should a new bug be created?