Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 52953 - On a diskless workstation X server doesn't set correct permissions to unix socket
On a diskless workstation X server doesn't set correct permissions to unix so...
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-08-31 07:03 EDT by Gabriele Turchi
Modified: 2007-04-18 12:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-06 14:12:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gabriele Turchi 2001-08-31 07:03:50 EDT
Description of Problem:

On a diskless workstation (the root file system is mounted from a
roswell-based system with v3,nolock,rsize=8192,wsize=8192 flags) the X
server leave its unix socket (/tmp/.X11-unix/X0) with permissions 0755, and
only root-owned client can connect. If I do a chmod 777 by hand, the normal
behaviour is back. I've done a test mounting a nbd (network block device)
file system under tmp, and the normal behaviour reappeared. This appear as
a bug in nfs/knfsd code.
I've also tryed to mount a different nfs file system as tmp, with flags as
lock or noac, but nothing changed. The kernel running on the diskless
worstation is a standard (redhat) 2.4.6 kernel for i686 with compiled in
the network module (8139too) and the nfs client module, with nfs root
option enabled.
Gabriele Turchi

P.S.: My english is alpha version...

Version-Release number of selected component (if applicable):
kernel 2.4.6 redhat

How Reproducible:
Every time

Steps to Reproduce:
1. Configure a diskless workstation
2. login as normal user
3. startx 

Actual Results:
X will start, but no application is started

Expected Results:
normal X session (gnome, in my case) startup

Additional Information:
Comment 1 Mike A. Harris 2001-09-01 15:58:33 EDT
Comment 2 Gabriele Turchi 2001-09-03 02:33:29 EDT
Standard flags for a nfs root are obviously rw and no_root_squash. Apparently
any other service (as writing the mtab in /etc) runs well (xfs too).

Gabriele Turchi
Comment 3 Gabriele Turchi 2001-09-03 07:32:14 EDT
Some more test done. I've updated the kernel on the diskless client to vanilla
2.4.9 without results, but the problem disappeared updating the server kernel to
the same vanilla (with jbd/ext3 patches only). (The original kernel was 2.4.6-3.1)

Gabriele Turchi
Comment 4 Mike A. Harris 2002-02-05 12:23:31 EST
This sounds more like a kernel NFS issue than an XFree86 issue.

Does it occur with our current RHL 7.2 erratum kernel 2.4.9-21?
Comment 5 Gabriele Turchi 2002-02-08 04:28:34 EST
Apparently not. 

I'm using a kernel 2.4.9-21 recompiled using standard athlon config file with
added NFS root file system support and tulip, sis900 and rtl8139 drivers built in.
Comment 6 Mike A. Harris 2002-02-08 14:43:48 EST
Just to confirm what you mean - aparently not what?

Does 2.4.9-21 work as supplied in binary form by Red Hat?
Comment 7 Alan Cox 2002-02-08 14:49:05 EST
Our base kernel doesn't have NFS root so that is tricky to get him to check. I
agree it looks like a kernel issue. Firstly its a wonder it works at all because
AF_UNIX sockets are not defined over NFS 8)

The traditional workaround is to use localhost:0 as the socket.

Nevertheless I'd like to know why it failed. Is this reproducable on a
conventional box with /tmp NFS mounted. 
Comment 8 Gabriele Turchi 2002-02-10 07:00:45 EST
I'm sorry, I've done a mistake. As I wrote in my first posting, the problem
appear to belongs to 2.4.6 kernel (roswell) knfsd. With different kernel on the
server (2.4.9 vanilla or RedHat) the problem vanished.

My last test was to upgrade _client_ kernel as described, but the server was
updated to standard RedHat 7.2 some months ago (without any problem).

Now, I think the right answer to Harris question is: the problem doesn't occour
with standard 7.2 kernel.

Alan, I don't know what to think: ls say that (on the server)

  [root@roccia dl01]# ls -la tmp/.X11-unix/X0 
  srwxrwxrwx    1 root     root            0 feb 10 12:32 tmp/.X11-unix/X0

and on the client:

  [root@dl01 root]# ls -la /tmp/.X11-unix/X0 
  srwxrwxrwx    1 root     root            0 feb 10 12:32 /tmp/.X11-unix/X0

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