Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Sun, 16 May 1999 21:31:14 +0100 (BST), Julian Gilbey wrote:
>> >> >And having mktex{mf,tfm,pk}
>> >> >writing to a scratch directory defeats the purpose of making the fonts
>> >> >directory read only, as anyone could then create a corrupt font file
>> >> >in the scratch directory and run mktexupd.
>> >>
>> >> This is a problem, but isn't there some simple, efficient way to
>> >> validate font files?
>> >
>> >Yes: recreate them and compare the outputs. You don't want to just
>> >check that the files are valid, but also that they have the correct
>> >content.
>>
>> Ok, I give up, we do have to do it your way.
>
>Yes, it's something I struggled with a few years ago in our department
>where corrupt fonts had been created: there was no simple way to
>determine this fact without recreating them. (You could compare the
>embedded checksums with those in the corresponding tfm, but how do you
>know that is correct if the tfm is also autogenerated?)
The main reason I didn't want to have mktex{mf,tfm,pk} be setuid is
because they run all sorts of different programs - metafont, gsftopk,
etc. - which can (IIRC) be replaced by the user. Even if they can't,
their inputs can, and the inputs are turing-complete macro languages.
If mktex{mf,tfm,pk} drop privileges before invoking the real generator
programs, I'll be happy.
I would also rather not install suidperl if it can be avoided.
zw
Reply to: