This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 129622 - xfs fails to start
xfs fails to start
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks: FC3Blocker
  Show dependency treegraph
 
Reported: 2004-08-10 19:08 EDT by Jeremy Katz
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-09 17:42:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2004-08-10 19:08:04 EDT
xfs fails to start on a fresh boot with
xorg-x11-6.7.99.0-0.2004_08_05.1 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-10 20:16:26 EDT
This is the relevant change in CVS:

http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/lib/xtrans/Xtransutil.c?r1=1.3&r2=1.4&diff_format=l

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-10 20:31:22 EDT
There's an upstream bug for this now:

https://freedesktop.org/bugzilla/show_bug.cgi?id=1029
Comment 3 Jeremy Katz 2004-08-10 23:35:13 EDT
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-10 23:58:58 EDT
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 00:01:43 EDT
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 00:11:09 EDT
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 00:31:23 EDT
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 04:38:06 EDT
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=$?
    [ $ret -eq 0 ] && touch /var/lock/subsys/xfs


Does this seem sufficient to resolve our local issue?
Comment 10 Bill Nottingham 2004-08-11 13:10:23 EDT
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 17:16:02 EDT
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 17:42:08 EDT
I've set "XtransFailSoft YES" in host.def in 6.8.0-1.  Please test
and reopen if these issues persist.

Thanks.

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