From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4
Description of problem:
The font cache is creating problems on a SElinux strict system,
since it is located at $HOME. Since the file is created in the
libfontconfig library, it is difficult to label properly
without placing SELinux code in the library, which is not desirable.
So, can the font cache on Fedora please be moved to $HOME/.fonts/auto
or somewhere else, where it is in a directory by itself. We
can then create that directory ahead of time by some mechanism,
label it properly, and it will work fine on a SELinux strict system.
Currently we create a bunch of those directories with a profile script,
but that's an ugly solution, and we'll likely change that.
One way or the other, however, the font cache should be moved
to its own directory - it should not clutter up $HOME.
Please see <cache> in fonts.conf.
Version-Release number of selected component (if applicable):
By font cache I am referring to the per user cache, automatically
managed by libfontconfig.
What is the status of this bug?
SELinux strict policy currently requires that the font
cache be moved to work properly. Without this change,
programs are not allowed to read or write the font cache.
Ivan, would it be enough to add
to /etc/fonts/fonts.conf ?
It needs to be a directory by itself, or it can't get auto-labeled properly.
If you put it in .fonts, SElinux can't tell it apart from other files in there
(fonts?). If it goes in a subdirectory, we can create the subdirectory ahead of
time, and label it as the font cache directory.
Then programs can be granted the right to write to the font cache directory, but
not the right to write to fonts.
Steven, does this sound right?
I'm not sure if it's okay or not to let programs write to .fonts, but I'm pretty
sure we don't want to let random programs write to $HOME just to make use of
Okay so we'll just need to create a ~/.fc-cache or something and throw it there.
This should be fixed in tomorrow's rawhide, I think. It is now stored in