Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Fri, 14 May 1999 19:04:01 +0100 (BST), Julian Gilbey wrote:
>> On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
>> >> Glad to hear all of this. I just have one comment:
>> >>
>> >> > - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
>> >> > If they are, anyone could run them, which is unnecessary. Any
>> >> > extra privileges they require will be gained when they are called
>> >> > from other setuid processes.
>> >>
>> >> It seems to me that *only* these three should be setuid, since only
>> >> these three need elevated privileges. mktextfm, etc. should be
>> >> changed to write the output into a scratch directory, and have
>> >> mktexupd move it into place.
>> >>
>> >> Yes, this does mean anyone can invoke them, but if properly designed
>> >> no damage can be done, and this restricts the scope of the changes and
>> >> the scope of the specially privileged code much better.
>> >
>> >No, absolutely not. If mktexupd is setuid, then anyone can make it do
>> >anything to the ls-R file, I would guess.
>>
>> Only if mktexupd is misdesigned; it ought to be capable of validating
>> updates.
>
>How?
The proper location for a file to be installed in /var/spool/texmf is
uniquely determined by its name, right? You hand it a file, and it
puts it where it belongs. No other changes to ls-R are possible via
(this version of) mktexupd
Moot, though, given what you say below.
>> >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.
zw
Reply to: