Bug 79119 - X crashes after recent updates, could not open default font 'fixed'
X crashes after recent updates, could not open default font 'fixed'
Product: Red Hat Linux
Classification: Retired
Component: kdebase (Show other bugs)
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Ngo Than
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-12-05 18:35 EST by Need Real Name
Modified: 2007-04-18 12:48 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-09 07:21:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Here is an untested patch that fixes this and a type (chkfontpath, not chfontpath) (554 bytes, patch)
2002-12-06 13:47 EST, Need Real Name
no flags Details | Diff

  None (edit)
Description Need Real Name 2002-12-05 18:35:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021128

Description of problem:
After installing the batch of kde updates from up2date yesterday, and rebooting,
X failed to start with the following message:

could not open default font 'fixed'

I found that this had happened because


had become not world readable.  Making it world readable and restarting xfs
fixed the problem.

This happened on two of my machines.
Comment 1 Mike A. Harris 2002-12-06 09:05:08 EST
I don't see how this is even possible.  Our mkfontdir is patched to
forcibly set the permissions on fonts.dir and encodings.dir to 0644
and ignore umask on purpose to avoid problems like you're describing.

Are you using Red Hat supplied XFree86?  Or did you recompile it yourself
or use an alterative version?
Comment 2 Need Real Name 2002-12-06 13:18:44 EST
I've seen this on some of our machines here as well.
Comment 3 air_ogi 2002-12-06 13:46:21 EST
if umask is 077 (as autorpm sets it , and up2date does as well I think) , kdebase 
RPM will run mkfontdir and set fonts.dir to 600.  
Comment 4 Need Real Name 2002-12-06 13:47:29 EST
Created attachment 87724 [details]
Here is an untested patch that fixes this and a type (chkfontpath, not chfontpath)
Comment 5 Mike A. Harris 2002-12-06 13:52:21 EST
I think you misunderstood what I'm saying above.  Our mkfontdir executable
has been modified itself internally to forcibly set the mode of the fonts.dir
and encodings.dir files to 0644 and totally ignore the umask.

If umask is set incorrectly, mkfontdir will create fonts.dir files
that are unreadable by regular users possibly.  I can't particularly
see any value to mkfontdir honoring umask.  Patch sets the file permissions
to 0644 for both fonts.dir and encodings.dir files.
Mike A. Harris
--- xc/programs/mkfontdir/mkfontdir.c.mkfontdir-perms   Mon Aug 20 10:00:57 2001
+++ xc/programs/mkfontdir/mkfontdir.c   Fri Nov  2 00:52:14 2001
@@ -204,6 +204,7 @@
        fprintf (file, "%s %s\n", entry->u.bitmap.fileName, entry->name.name);
     fclose (file);
+    chmod(file, 0644);
     return TRUE;
@@ -235,6 +236,7 @@
         fprintf(file, "%s %s%s\n",
                 encoding->name, prefix, encoding->fileName);
+    chmod(file, 0644);
     return TRUE;
The above is a patch that we apply to XFree86 sources of mkfontdir
to do this.

However, your patch does fix a bug in kdebase, and the forced umask
ahead of mkfontdir certainly does not harm anything.  I force umask
in XFree86.spec as well for redundancy already.
Comment 6 Need Real Name 2002-12-06 14:03:17 EST
Hmm, I'm using RedHat 7.3. Has that mkfontdir been patched as well?

Here's what I see:

[root@lassie root]# cat /etc/redhat-release 
Red Hat Linux release 7.3 (Valhalla)
[root@lassie root]# rpm -qf /usr/X11R6/bin/mkfontdir
[root@lassie root]# umask 077; /usr/X11R6/bin/mkfontdir 
[root@lassie root]# ls -l /usr/X11R6/lib/X11/fonts/misc/fonts.dir 
-rw-------    1 root     root        19518 Dec  6 11:02 
[root@lassie root]# 
Comment 7 Mike A. Harris 2002-12-06 15:23:50 EST
Yes it is supposed to do that in RHL 7.3 as well.  Aparently, if you
are using mkfontdir supplied by our packages, it is not working as
expected.  Hmm.  I will investigate, thanks.
Comment 8 Mike A. Harris 2002-12-06 15:28:28 EST
I've found a bug in mkfontdir, and will have it fixed in all future X
release erratum.

So there is indeed 2 things going wrong here.

1) Every package maintainer calling mkfontdir, should personally make
   sure that "umask 133" precedes it, just to make damn sure it works properly.

2) My safeguard patch to mkfontdir fails to properly chmod the files, which
   also goes unnoticed.

Comment 9 Need Real Name 2002-12-06 18:31:40 EST
There is a fundamental problem with chmod.  It takes a const char *, not
a FILE *.  So likely is is trying to chmod("", 644), which likely will fail
for non-root users.  Maybe a fchmod(fileno(file), 644) before the close would
fix this.

Comment 10 Mike A. Harris 2002-12-06 21:32:57 EST
Yes, that was the problem I discovered.  Instead of passing chmod the
filename, when I wrote the patch I inadvertently passed it a file
descriptor.  Tested it by upgrading X and looking at the generated
file perms with umask set to 077.  It worked, so I assumed it to be
correct.  This is the first bug report ever reported showing that it
indeed does not work as expected.  The problem was masked because
the XFree86 spec file, and all other spec files I've gotten my hands
on explicitly use "umask 133" prior to calling mkfontdir.

Ultimately this is a packaging bug in packages that call mkfontdir,
because they should set the umask first.  I've discussed my chmod
patch with XFree86.org and they claim that the patch is not necessary
and that it is the responsibility of the sysadmin/OS to set umask

Personally, I disagree.  I can't think of any valid reason why mkfontdir
should *not* force mode 0644 on these files.  If anything, I think
it should default to mode 0644, and hame a new commandline switch to
override this with some other permission setting if desired.  I've fixed
the current bug in the patch, and am going to see if they'll accept a
patch that offers a commandline switch to allow setting of the
permissions instead, and default to 0644.

Comment 11 Mike A. Harris 2002-12-06 21:56:46 EST
Cc'ing than for KDE issue
Comment 12 Mike A. Harris 2002-12-08 06:25:28 EST
I have created a new patch to mkfontdir which I've tested heavily now and
ran it on my system for several days, with an automated script calling
mkfontdir once every 10 minutes in all font directories with random umask
values, and it works properly as expected now.

I've backported this patch to 4.2.1 and 4.1.0 also, and any future Red Hat
erratum releases of XFree86 will come with this mkfontdir enhancement.

I'm reassigning this bug to kdebase now though as that is the buggy
component in this case, not XFree86.  It is imperative IMHO that we
release updated kdebase ASAP to minimize the number of users affected
by this problem.
Comment 13 Ngo Than 2002-12-08 10:55:57 EST

i don't think adding umask 133 before mkfontdir is a fix to this problem.
It's obvious a major bug in mkfontdir, which has to be fixed and released as
errata ASAP. Doing new kdebase errate is not a good solution here.

You cannot expect that rpm packager has to add this workaround "umask 133" in rpms 

Perhaps kdebase in 7.2/7.3 seems to have this problem too!
Comment 14 Ngo Than 2002-12-09 07:21:46 EST
kdebase-3.0.3-15 will fix this problem.

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