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?

I've seen this on some of our machines here as well.

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.  

Created attachment 87724 [details]
Here is an untested patch that fixes this and a type (chkfontpath, not chfontpath)

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);
     fclose(file);
+    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.

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
XFree86-font-utils-4.2.0-8
[root@lassie root]# umask 077; /usr/X11R6/bin/mkfontdir 
/usr/X11R6/lib/X11/fonts/misc
[root@lassie root]# ls -l /usr/X11R6/lib/X11/fonts/misc/fonts.dir 
-rw-------    1 root     root        19518 Dec  6 11:02 
/usr/X11R6/lib/X11/fonts/misc/fonts.dir
[root@lassie root]# 

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.

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.

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.

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
appropriately.

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.

Cc'ing than for KDE issue

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.

Mike,

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!

kdebase-3.0.3-15 will fix this problem.