Bug 55597

Summary:	NFS-mounted X server creates socket with bad permissions
Product:	[Retired] Red Hat Linux	Reporter:	Christopher Wong <chris>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED CURRENTRELEASE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-06-07 20:17:19 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 Christopher Wong 2001-11-02 18:11:45 UTC

Description of Problem:

This happens to a diskless workstation that mounts its root filesystem 
over NFS. When X runs on this diskless PC, the Unix domain socket for X 
is created at /tmp/.X11-unix/X0 with permissions srwxr-xr-x with owner 
and group root. This makes it impossible for a nonroot user to start X on 
a console. The attempt would fail after some time with:

giving up.
xinit: Permission denied (errno 13): unable to connect to X server
waiting for X server to shut down.
xinit: Server error. 

Normally on non-NFS-mounted PCs, /tmp/.X11-unix/X0 is created with 
permission srwxrwxrwx. If I change the socket to this less restrictive 
permission after it is created, the X startup would proceed successfully. 
Because the diskless PC is using an old SIS 6326 video chipset, I am 
using a 3.3.6 X server XFree86_SVGA rather than one of the 4.x ones.

Comment 1 Mike A. Harris 2001-11-05 13:29:35 UTC

This is a specialized configuration of XFree86 that Red Hat does
not support.  It is most likely a general XFree86 problem, and not
one specific to Red Hat Linux.  I recommend reporting it upstream
to XFree86 directly.  You may be able to receive some guidance on
the XFree86 xpert users mailing list.

Hope this helps.

Comment 2 Christopher Wong 2001-11-05 21:54:22 UTC

The problem appears to be with 7.1's kernel. The XFree86 xpert list that you 
suggested I subscribe had this reply from Dr. Martin Kroeker (mk):

"If this happens with anything that gets created in the nfs-mounted
filesystem, it is a kernel (nfsd) bug present in older 2.4.x kernels 
(x being something like <7). Check the kernel mailing list archive for
correct details, but in essence the initial umask was changed to 022 so 
that nobody can play tricks with init, and nobody noticed that the 
kernel-based nfsd inherits the same umask. Upgrading the kernel should fix
this."

Comment 3 Mike A. Harris 2001-11-06 03:47:04 UTC

Ok, this is good to know in case someone else reports the problem,
or queries for it in bugzilla.  Do you know what kernel it was
fixed in?

Arjan, can you comment on this umask issue with knfsd?

Comment 4 Mike A. Harris 2001-11-06 03:48:07 UTC

I'll close it as resolved in foo, when we find out what value of foo
to use.  Thanks.

Comment 5 Mike A. Harris 2001-11-06 03:48:19 UTC

I'll close it as resolved in foo, when we find out what value of foo
to use.  Thanks.

Comment 6 Arjan van de Ven 2001-11-06 10:02:52 UTC

Does this still happen with the 2.4.9-12 errata kernel?

Comment 7 Christopher Wong 2002-01-09 21:21:36 UTC

I have tested on the errata kernel-2.4.9-13 under Red Hat 7.2, and can verify that 
this problem is not present on that version.