Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 456157 - Xorg does not work with abstract Unix sockets
Summary: Xorg does not work with abstract Unix sockets
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-xtrans-devel
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 461987 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-21 19:44 UTC by Sami Farin
Modified: 2018-04-11 07:02 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-31 14:24:12 UTC


Attachments (Terms of Use)
attempt to fix abstract sockets (deleted)
2008-09-12 21:25 UTC, Sami Farin
no flags Details | Diff
abstract socket support (deleted)
2008-09-13 15:32 UTC, Sami Farin
no flags Details | Diff

Description Sami Farin 2008-07-21 19:44:41 UTC
Description of problem:
19:33:47.138852 connect(3, {sa_family=AF_FILE, path=@/tmp/.X11-unix/X0}, 110) =
-1 ECONNREFUSED (Connection refused) <0.000024>
19:33:47.138959 connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) =
-1 ENOENT (No such file or directory) <0.000055>

I don't know why it is not listening on the abstract socket.
strace shows Xorg has called listen() for it:
14839 18:55:55.790179 socket(PF_FILE, SOCK_STREAM, 0) = 4 <0.000020>
14839 18:55:55.790238 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024,
rlim_max=10*1024}) = 0 <0.000012>
14839 18:55:55.790299 umask(0)          = 077 <0.000012>
14839 18:55:55.790353 bind(4, {sa_family=AF_FILE, path=@/tmp/.X11-unix/X0}, 20)
= 0 <0.000015>
14839 18:55:55.790414 listen(4, 128)    = 0 <0.000012>

maybe Xorg closed the fd....?

# grep @/tmp/.X11 /proc/net/unix
ffff8100bc0d8980: 00000002 00000000 00010000 0001 01 1957726 @/tmp/.X11-unix/X0

Version-Release number of selected component (if applicable):
xorg-x11-xtrans-devel-1.2.1-2

How reproducible:
always

Steps to Reproduce:
1. start Xorg
2. as other user than the one who started Xorg, try to connect to :0.0.  it
fails, because his /tmp is in different namespace.
3. 

I would need to hard link the correct X0 file to every user's own
/var/tmp-inst/XXX/.X11-unix/X0 to make the thing work.

Actual results:
no X apps can be started

Expected results:
X apps can be started

Additional info:
X.Org X Server 1.4.99.905 (1.5.0 RC 5)

Comment 1 Matěj Cepl 2008-07-22 07:17:48 UTC
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

I suspect SELinux here. Can we get output of these commands, please?

/sbin/ausearch -m AVC |grep X11

(output of this one would be better to be attached as a file attachment to this
report, as it can get pretty large)

and

/usr/sbin/getenforce

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 2 Sami Farin 2008-07-22 17:40:11 UTC
selinux is disabled because it just does not work for me.

ausearch outputs something useless from year 2006.


Comment 3 Sami Farin 2008-09-12 17:31:49 UTC
I made a patch to libxcb and it fixed the issue, then I found that yesterday someone had posted a similar patch at:
https://bugzilla.redhat.com/show_bug.cgi?id=461987

Comment 4 Matěj Cepl 2008-09-12 20:19:53 UTC
You won. That other patch is attachment 316471 [details].

Comment 5 Matěj Cepl 2008-09-12 20:20:04 UTC
*** Bug 461987 has been marked as a duplicate of this bug. ***

Comment 6 Ted X Toth 2008-09-12 21:01:31 UTC
Unfortunately the latest libxcb 1.1.91-2 with the fixed connect doesn't resolve this problem for me. When I do a netstat -a | grep X0 I expect the connected clients to be using @/tmp/.X11-unix/X0 but they aren't. When I first applied my patch to libxcb 1.1-4 and updated my machine I could have sworn that all of the clients connected to the abstract namespace socket but maybe I was hallucinating ...

Comment 7 Sami Farin 2008-09-12 21:24:12 UTC
Well this patch on top of 1.1-4 works for me.
And I am not hallucinating.
00:07:23.054687 connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"...}, 20) = 0 <0.000023>
whereas without the patch it returned -1 .
When I fire up extra xterm, number returned by
netstat -an|grep -c "@/tmp/.X11-unix/X0"
increases by one.

About the patch: using strcpy is maybe enough (no need for strncpy), but I don't bother reading enough code to say for sure.
And I don't know does it work if HAVE_SOCKADDR_SUN_LEN is defined (is it even possible on Fedora systems?), because I don't bother wasting time finding out would it work.

Comment 8 Sami Farin 2008-09-12 21:25:32 UTC
Created attachment 316625 [details]
attempt to fix abstract sockets

Comment 9 Ted X Toth 2008-09-13 14:00:52 UTC
I went back to using 1.1-4 with my original patch and now all clients connect to the abstract namespace socket. I'm not sure what the difference is in 1.1.91-2 but it seem to affect the abstract socket connect negatively.

Sami could you try installing 1.1.91-2 and see if you get the same result as I'm getting?

Comment 10 Sami Farin 2008-09-13 14:07:49 UTC
if you tell where to get it from,
ftp://download.fedora.redhat.com/%2Fpub/fedora/linux/development/source/SRPMS/
has only 1.1.91-1.

Comment 12 Sami Farin 2008-09-13 14:18:48 UTC
yes, I checked the source, but did not compile...  obviously it does not work because socket() call is after connect call when attempting abstract socket, so fd has undefined value.

Comment 13 Ted X Toth 2008-09-13 14:38:41 UTC
Compiled fine for me but it does look like the patch is inserted at the wrong line :(

Comment 14 Sami Farin 2008-09-13 14:51:35 UTC
I meant "... but I did not compile", not "... but libxcb did not compile" ;-)
It works if you just move the socket call earlier.

Comment 15 Ted X Toth 2008-09-13 15:25:07 UTC
So you'll submit a new patch?

Comment 16 Sami Farin 2008-09-13 15:32:41 UTC
Created attachment 316668 [details]
abstract socket support

Comment 17 Ted X Toth 2008-09-24 15:01:48 UTC
Could someone please rebuild this as libxcb-1.1.91-2.fc10 has the broken patch.

Comment 18 Colin Walters 2008-09-24 18:25:33 UTC
In what situation do you have a uid not equal to the owner of the server connecting?

Is this bug basically that consolehelper doesn't work with polyinstantiated /tmp?

Comment 19 Sami Farin 2008-09-24 18:37:27 UTC
To Walters: when I do "su -l luser" and start some X app.

Comment 20 Colin Walters 2008-09-30 14:01:22 UTC
You should not expect that kind of thing to continue to work going forward.  The reason is because allowing another uid access to your X session effectively gives them control over your entire desktop (i.e. all programs running as your uid).

Thus, you should either simply run the program as your own uid, or run the program in a new X session (in GNOME, select you name in the top right and log in as that user).

Comment 21 Colin Walters 2008-10-03 21:50:21 UTC
I am removing this from the blocker list for the reason in comment #20.

Comment 22 Adam Jackson 2008-10-31 14:24:12 UTC
Built 1.1.91-4 in rawhide, closing.


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