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@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
