[Fontconfig] What to do with $HOME is unset

[Keith Packard]

I'm reading through a bug report in the debian bug system:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387928

It raises an interesting question on how fontconfig handles the case
when $HOME is unset (or unwritable). When this happens, fontconfig is
unable to write any cache files to disk, making application performance
suffer terribly when some cache data is outdated or missing.

I'm wondering if we shouldn't use a /tmp scheme as a part of the cache
directory path. Would this make sense, and if so, how would we structure
the names? 

One important thing to remember here is that we want to be able to trust
cache files and not spend a lot of time scanning them for intentional
(or unintentional) errors. That means we need reasonable security
against spoofing.

I would like to solicit suggestions on secure schemes for placing cache
files in /tmp; I have one suggestion, I hope others can come up with
further ideas.

My thought is that we create regular files in /tmp that contain the
username as a part of the filename, after the file is open, check the
UID of the resulting file and refuse to use the cache if the UID doesn't
match. This, unfortunately, provides a DoS opportunity though.

Experiences with /tmp/.X11-unix make it clear that directories in /tmp
are 'hard' to secure, that seems like a way to avoid DoS issues if we
can ensure that the directory name itself can be created.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20060924/dc517a4a/attachment.pgp