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