Re: Braindump: Can we get rid of the font-cache-group question?

[Florent Rougon <f.rougon@free.fr>]

Hi,

Frank Küster <frank@debian.org> wrote:

>> But IMHO, there is a race condition: I think it is possible that
>> libkpathsea (or mktex*) checks and finds that /tmp/texfonts/somepkfile
>> does not exist; then the attacker quickly creates
>> /tmp/texfonts/somepkfile as a symlink to some file he wants to ovewrite;
>> and eventually, mktexpk writes the font data to that symlink, which is
>> baaad...
>
> Isn't this a general problem, no matter where the fonts are cached?  

Yes. However, in the current setup, only the members of one specific
group can do the attack.

> And does it work at all?  He's allowed to create the symlink, but not to
> change the file it points to.

Of course, the symlink has to point to a file that is writable by the
user who will run mktexpk. E.g., I could probably overwrite your .zshrc
with font data. In the best case, you'll be very annoyed to have your
configuration lost. In the worst case, you may be unable to login (I
don't know, I didn't test that).

BTW, about the /tmp/texfonts directory, won't it be a problem if one
user creates it (not manually, but as suggested in this thread, by way
of mktexnam or whatever kpathsea program) and then, *another user* also
needs it to store fonts? Under normal circumnstances, the second user
won't have the permissions to write to /tmp/texfonts.

I didn't follow the discussion very closely, so I may say something
wrong here. If I understood correctly, /tmp/texfonts would be only used
for a user who has no $HOME and thus cannot write the font data to
TEXMFVAR. If this is right, the previous paragraph could only happen
with such users (buildds?), but still, it may happen...

-- 
Florent