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
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.
There's an upstream bug for this now: https://freedesktop.org/bugzilla/show_bug.cgi?id=1029
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: 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?
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. -Chris Kuivenhoven
I've set "XtransFailSoft YES" in host.def in 6.8.0-1. Please test and reopen if these issues persist. Thanks.