Bug 129622

Summary: xfs fails to start
Product: [Fedora] Fedora Reporter: Jeremy Katz <katzj>
Component: xorg-x11Assignee: Mike A. Harris <mharris>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: chris, notting, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-09 21:42:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 130887    

Description Jeremy Katz 2004-08-10 23:08:04 UTC
xfs fails to start on a fresh boot with
xorg-x11- packages.

Failure is (based on strace)
lstat("/tmp/.font-unix") = ENOENT
write("_FontTrans - mkdir: ERROR: euid != 0, directory /tmp/.font-unix
will not be created)

Just above the xfs start in the xfs init script is rm -fr /tmp/.font-unix

Comment 1 Kristian Høgsberg 2004-08-11 00:16:26 UTC
This is the relevant change in CVS:


It's a security related change, it has to do with the /tmp/.font-unix
dir not being owned by root.  If a user can chown this dir and clear
all permissions on it, xfs refuse to start, i.e. DoS.  The fix was
introduced primarily for the X server, but both the server and xfs use
xtrans so the change affect both.

The X server has a different behaviour though if /tmp/.X11-unix is not
owned by root - it just chowns it and starts up normally.  xfs can't
do this, since it's not a priviledged process, so it just bails.

I think the fix is to just chown+chmod /tmp/.font-unix in the %post
section of the RPM.

Comment 2 Kristian Høgsberg 2004-08-11 00:31:22 UTC
There's an upstream bug for this now:


Comment 3 Jeremy Katz 2004-08-11 03:35:13 UTC
Just doing it in the %post isn't good enough.  If you have /tmp on
ramfs, then it gets recreated on every boot.  Also relevant if you end
up using tmpwatch on /tmp (common in lots of environments)

Comment 5 Mike A. Harris 2004-08-11 03:58:58 UTC
rc.sysinit creates /tmp/.font-unix now I think.  If not, I just
CC'd Bill for his thoughts.

Another option is a SUID helper to do this for xfs, which seems
a bit wonky of a solution IMHO, but I can't think of any other
solution offhand personally.

Comment 6 Mike A. Harris 2004-08-11 04:01:43 UTC
X Devel Team:  What do you think about removing the line from the
xfs initscript: "rm -rf /tmp/.font-unix" and relying on the X server
and rc.sysinit to set this up for now?

If that isn't enough, what is everyone's thoughts on getting someone
to write a SUID helper to do this?

Comment 7 Bill Nottingham 2004-08-11 04:11:09 UTC
No, rc.sysinit just handles ICE-unix.

In any case, if xfs will fail if it isn't there, we probably shouldn't
remove it before hand, or at least try to remake it after removing it.

Comment 8 Kevin E. Martin 2004-08-11 04:31:23 UTC
I've added comments in the upstream bug report that this change might
have unintended consequences and that the change might need to be
backed out.  For example, some other non-setuid-root program might
want to use xtrans, and it would have suffer the same failures.

Comment 9 Mike A. Harris 2004-08-11 08:38:06 UTC
I commited the following to our xorg-x11 xfs.init script:

Index: xfs.init
RCS file: /cvs/pkgs/rpms/xorg-x11/xfs.init,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- xfs.init    11 Aug 2004 04:26:24 -0000      1.2
+++ xfs.init    11 Aug 2004 04:36:23 -0000      1.3
@@ -69,9 +69,16 @@

 start() {
+   FONT_UNIX_DIR=/tmp/.font-unix
    echo -n $"Starting $prog: "
    [ -x /usr/sbin/chkfontpath ] && buildfontlist
-   rm -fr /tmp/.font-unix
+   # Clean out .font-unix dir, and recreate it with the proper
ownership and
+   # permissions.
+   rm -rf $FONT_UNIX_DIR
+   mkdir $FONT_UNIX_DIR
+   chown root:root $FONT_UNIX_DIR
+   chmod 1777 $FONT_UNIX_DIR
    daemon xfs -droppriv -daemon
    [ $ret -eq 0 ] && touch /var/lock/subsys/xfs

Does this seem sufficient to resolve our local issue?

Comment 10 Bill Nottingham 2004-08-11 17:10:23 UTC
If it's a security issue if it has the wrong permissions, you *may*
want to bail if the mkdir fails.

Comment 11 Chris Kuivenhoven 2004-09-04 21:16:02 UTC
FYI, the upstream bug is now marked resolved. Upstream added an option
'XtransFailSoft' to allow people to revert to the 6.7 behavior and
committed to CVS around 8/30/04.

-Chris Kuivenhoven

Comment 12 Mike A. Harris 2004-09-09 21:42:08 UTC
I've set "XtransFailSoft YES" in host.def in 6.8.0-1.  Please test
and reopen if these issues persist.