+++ This bug was initially created as a clone of Bug #212166 +++ Two issues in XFree86/xorg Xsession were reported and fixed upstream. Both relate to the handling of the xsession file. CVE-2006-5214: A local attacker could open for reading a users ~/.xsession-errors file if they are able to win a race during it's creation and have sufficient privileges (+x) to the victims home directory already. CVE-2006-5215: A local attacker could perform a temporary file attack on the xsession error file created in /tmp and cause it to overwrite particular files of the victim. However this file is only created if the ability to create ~/.xsession-errors in the victims home directory fails, (something the attacker has no control over). The upstream Xsession code was different (and worse) than our xinitrc code, but we should use mkstemp. We've rated these issues as low severity and they can be deferred until a future update for some other reason. This affects Xsession as shipped in xorg-x11-xinit in FC6 and FC5 and xorg-x11-xdm in FC5 only (FC6 contains a fixed upstream version) Affects: FC6, FC5 Note also affects xinitrc (bz#210311)
fix: http://webcvs.freedesktop.org/xorg/app/xdm/config/Xsession.cpp
Sandmann: Could you please fix this for FC6 and push updated?
xorg-x11-xinit-1.0.2-21.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Reopening this for FC6.
After my latest "yum update", X refused to start, either for rhgb or for normal usage if "rhgb" was removed from the boot line. I booted into single user mode, reverted the xorg-x11-xinit update (i.e. did rpm -Uvh --oldpackage to get the old package back), and then the problem was gone.
Forgot to mention that this was on a fully updated F7 system.
Do you remember which package exactly caused the problem? Was it 1.0.2-22 or 1.0.2-21? What exactly happened. Ie,. what does 'refused to start' mean?