Red Hat Bugzilla – Bug 129622
xfs fails to start
Last modified: 2007-11-30 17:10:47 EST
xfs fails to start on a fresh boot with
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
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.
There's an upstream bug for this now:
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)
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.
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?
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.
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.
I commited the following to our xorg-x11 xfs.init script:
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 @@
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
+ # 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?
If it's a security issue if it has the wrong permissions, you *may*
want to bail if the mkdir fails.
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.
I've set "XtransFailSoft YES" in host.def in 6.8.0-1. Please test
and reopen if these issues persist.