Description of problem: Due to something I missed in some "recovery actions" I managed to set 700 permission on /usr and I failed to notice that right away. This clearly put a spanner in xfs works as for every fonts.dir I got something like: open("/usr/X11R6/lib/X11/fonts/misc/fonts.dir", O_RDONLY) = -1 EACCES (Permission denied) when '-droppriv' was in use. So far so good, although X server got clearly unhappy, but that brought to light two problems. One is that I still got "[ OK ]" from /etc/rc.d/init.d/xfs even if 'service xfs status' was immediately reporting "xfs dead but subsys locked". The other is that when I tried to run 'xfs -droppriv' but in a foreground I got: *** glibc detected *** xfs: double free or corruption (!prev): 0x000000000051cd40 *** This seems to indicate that something is not right on an error handling path. Version-Release number of selected component (if applicable): xorg-x11-xfs-6.8.2-62 How reproducible: always in circumstances described above.
If possible, could you test FC5test2 or newer to see if the same problem still occurs?
Currently installed xfs is xorg-x11-xfs-1.0.0-2 and I do not see glibc complaints when fonts directories are unreadable. A process started with '-nodaemon -droppriv' just does not terminate. It still starts with an "OK" status even where is not a single font to serve. This may be expected.
Reading comment #2, it sounds like the problem reported in the initial report is fixed now, can you confirm that? It isn't clear if comment #2 is also trying to state a second bug is present or not, however if that is the case, a new bug report should be filed separately for each bug that is discovered for proper tracking/closure of each issue. TIA