[Xquartz-dev] ah-HAH! the precise problem here is … (Re: I got it working, but still potential problem (Re: Getting bad DISPLAY value during use of 2.6.1-2.6.2 (not with 2.6.0 & before).)

[Jeremy Huddleston]

Thanks for your response.  I'm was still a bit puzzled why you got the:
_XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 2

The message is actually misleading.  It's not that mkdir(/tmp/.X11-unix) failed, it's that trans_mkdir(/tmp/.X11-unix) failed for the reason mentioned on the line above it.  I started to build XQuartz with -DFAIL_HARD which will error out if /tmp/.X11-unix is not owned by root (to avoid man-in-the-middle attacks on your X11 socket).

So I think that finishes solving the riddle.

--Jeremy

On Apr 25, 2011, at 11:05 PM, SciFi wrote:

> 
> [I am using Gmane and Pan to reply.  Peek at the headers of this message, esp User-Agent. ;) ]
> 
> On Mon, 25 Apr 2011 11:32:00 -0700, Jeremy Huddleston wrote:
> 
>> On Apr 25, 2011, at 07:49, SciFi wrote:
>>> Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
>>> Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 2
>>> Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local
>> 
>> Are your /tmp permissions messed up?
> 
> /tmp is (still) a symlink to /private/tmp, the way Apple originally intended; I haven't change this.
> 
> $ ls -al /tmp
> lrwxr-xr-x 1 root wheel 11 Dec 26 07:50 /tmp -> private/tmp
> 
> $ ls -al /private
> total 0
> drwxr-xr-x  6 root wheel  204 Dec 26 08:01 .
> drwxrwxrwt 24 root wheel 1258 Apr 22 06:43 ..
> drwxr-xr-x 26 root wheel 4658 Apr 25 08:30 etc
> drwxr-xr-x  2 root wheel   68 May 18  2009 tftpboot
> drwxrwxrwt 11 root wheel  544 Apr 26 00:00 tmp
> drwxr-xr-x 26 root wheel  884 Dec 26 08:01 var
> 
> (I think, not sure, that /tmp is checked with the 'diskutil repairPermissions /' facility?  I run it after most-any system update.)
> 
>> 1) Any user should be able to mkdir(/tmp/.X11-unix) if it isn't present.
>> 2) root should be creating and sanitizing /tmp/.X11-unix via org.macosforge.xquartz.privileged_startx
> 
> Thanks for these pointers -- I now know the real problem.
> 
> 
>> [snip]
>> 
>>> Was this suppose to have been automatically done during another phase, somehow?
>> 
>> The org.macosforge.xquartz.privileged_startx LaunchDaemon, which is triggered by running /opt/X11/lib/X11/xinit/privileged_startx from /opt/X11/bin/startx from the org.macosforge.xquartz.startx LaunchAgent.
>> 
>>> What should we do in this case, please?
>> 
>> My guess is fix your /tmp permissions.
> 
> I am sure the /tmp permissions are okay (see above).
> But I am thankful for pointing me to where the real problem is, here on my system.
> 
> When I peeked into the files under /opt/X11/lib/X11/xinit/privileged_startx.d,
> I found the problem is with using 'mktemp' in the 10-tmpdirs script.
> The system here is picking up my $PATH, finding them first in /usr/local/bin,
> where I placed my own builds of the GNU-coreutils version of these tools,
> which sometimes have distinctly different usage patterns --
> when I ran those three dir's in that for-loop in 10-tmpdirs,
> GNU's mktemp says it needs at least 3 X's in the template
> and that is where we are failing.
> 
> I'm going to hard-code these tools, when they differ so much in usage,
> to use Apple's *BSD versions in the {,/usr}/bin tree,
> rather than any $PATH version.
> 
> That should fix everything with your new Xquartz I hope.  ;)
> 
> Unless you would rather go back with the previous/older way of creating these tmpdirs i.e. by not using mktemp.  ;)
> 
> Thank you again very much for taking time.
> 
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>