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)
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.
selinux is disabled because it just does not work for me. ausearch outputs something useless from year 2006.
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
You won. That other patch is attachment 316471 [details].
*** Bug 461987 has been marked as a duplicate of this bug. ***
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 ...
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.
Created attachment 316625 [details] attempt to fix abstract sockets
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?
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.
http://koji.fedoraproject.org/koji/buildinfo?buildID=62870
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.
Compiled fine for me but it does look like the patch is inserted at the wrong line :(
I meant "... but I did not compile", not "... but libxcb did not compile" ;-) It works if you just move the socket call earlier.
So you'll submit a new patch?
Created attachment 316668 [details] abstract socket support
Could someone please rebuild this as libxcb-1.1.91-2.fc10 has the broken patch.
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?
To Walters: when I do "su -l luser" and start some X app.
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).
I am removing this from the blocker list for the reason in comment #20.
Built 1.1.91-4 in rawhide, closing.