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@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
Le dimanche 24 septembre 2006 ? 11:09 +0100, Keith Packard a ?crit :> 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.We encountered a similar bug on Mandriva (see http://qa.mandriva.com/show_bug.cgi?id=25609 ) because /etc/fonts/fonts.conf wasn''t updated by rpm, since I never removed the noreplace config flag in our fontconfig package (but that is another story :) This "HOME not set" bug has been there for years and I''m still convinced we should try to minimize it by using getpwent when HOME is not set (since some people might want to override their HOME, even if I''m not sure it is a good idea). I''ll be happy to hack a patch for it (I did one a loong time ago) if it is going to be accepted for merge. -- Frederic Crozat <fcrozat@mandriva.com> Mandriva
On Mon, 2006-09-25 at 10:14 +0200, Frederic Crozat wrote:> This "HOME not set" bug has been there for years and I''m still convinced > we should try to minimize it by using getpwent when HOME is not set > (since some people might want to override their HOME, even if I''m not > sure it is a good idea).I''m also unsure we should override what appears to be a common method for avoiding issues with setuid programs; fontconfig itself explicitly ignores $HOME when running setuid. Some idea as to the security implications of writing (and reading) files from the getpwent value of the home directory would be very useful to have. Who can we ask?> I''ll be happy to hack a patch for it (I did one a loong time ago) if it > is going to be accepted for merge.Let''s figure out where we want to store files when $HOME isn''t set, either something in /tmp or finding the home directory from getpwent both seem possible, I also see potential issues with both. -- keith.packard@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/20060925/b5adfd7e/attachment.pgp
Le lundi 25 septembre 2006 ? 10:56 +0100, Keith Packard a ?crit :> On Mon, 2006-09-25 at 10:14 +0200, Frederic Crozat wrote: > > > This "HOME not set" bug has been there for years and I''m still convinced > > we should try to minimize it by using getpwent when HOME is not set > > (since some people might want to override their HOME, even if I''m not > > sure it is a good idea). > > I''m also unsure we should override what appears to be a common method > for avoiding issues with setuid programs; fontconfig itself explicitly > ignores $HOME when running setuid. Some idea as to the security > implications of writing (and reading) files from the getpwent value of > the home directory would be very useful to have. Who can we ask?Maybe glib people ?> > I''ll be happy to hack a patch for it (I did one a loong time ago) if it > > is going to be accepted for merge. > > Let''s figure out where we want to store files when $HOME isn''t set, > either something in /tmp or finding the home directory from getpwent > both seem possible, I also see potential issues with both.I wasn''t implying not to fix the $HOME isn''t set case, of course. Just making sure we don''t hit this case too often. BTW, if we go to the /tmp path, a corner case to remember is when /tmp isn''t readable by anybody (I know, it might sound strange, but some paranoiac people use this settings ;) -- Frederic Crozat <fcrozat@mandriva.com> Mandriva
On Sun, Sep 24, 2006 at 11:09:50AM +0100, Keith Packard wrote:> 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?I''d suggest a /tmp/.fc-cache/[whatever]. On systems with _lots_ of logged in users, this wouldn''t flood /tmp with an entry for every user. -- albert chin (china@thewrittenword.com)
On Tue, 2006-10-03 at 00:34 -0500, Albert Chin wrote:> On Sun, Sep 24, 2006 at 11:09:50AM +0100, Keith Packard wrote: > > 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? > > I''d suggest a /tmp/.fc-cache/[whatever]. On systems with _lots_ of > logged in users, this wouldn''t flood /tmp with an entry for every > user.that generates issues with symlink attacks as we discovered with /tmp/.X11-unix; without some caution; before we do this, I''d like a reasonably detailed description of how these files and directories could be built safely. -- keith.packard@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/20061003/23571eaf/attachment.pgp