Bug#390349: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

[Frank Küster <frank@kuesterei.ch>]

Ralf Stubner <ralf.stubner@web.de> wrote:

> On Sun, Oct 01, 2006 at 14:48 +0200, Frank Küster wrote:
>> The input can come from the current directory, the user's own TEXMF tree
>> or any directory specified in the MFINPUTS (etc.) variable.
>
> The output goes to the user's own TEXMF tree, though. If the input comes
> from a tree not defined is SYSTEXMF like some private TEXMF tree, then
> that tree is used for output as long as it is writable. If not, then the
> current directory is used (at least that'ss the way I understand
> mktexnam). 

I didn't check the mktexnam code - but I'm a little surprised here.  I
wasn't aware of the test for SYSTEXMF, but in case the test "fails",
i.e. the input is from a private TEXMF tree, shouldn't the output go to
TEXMFVAR ($HOME/.texmf-var), too?  And isn't VARTEXFONTS the fallback in
that case too, as it is if the input comes from a system tree?

> However, this system isn't all that secure since the user
> could easily add the private TEXMF tree to SYSTEXMF. But then, what  one
> can do with mktex* is rather limited, so the real problem is the write
> access, be it global or limited to some group.

Yes, that's my opinion, too.  In the long run, it might be worth fixing
that, though.

Julian's idea that I mentioned previously is in line with what you
describe in the first paragraph.  If I remember right, it goes
approximately like this:

- a wrapper written in C takes over, setuid "mktexfoo"

- identify input files

- Get rid of all environment variables, read the compiled-in texmf.cnf

- Test whether the input is from a system tree 

  * If yes, call existing mktex* script to put output into system tree

  * If no, check where the output goes:
 
    ° if it's a local output dir, drop priviledges and call existing
      mktex* script

    ° if it's a system-wide output dir, exit with an error

However, this requires some thorough thinking before implementing it,
careful coding, and in any case it is something to introduce upstream.

I repeat myself:  I do not think that we do have any serious problem.
The minor problems we have are much less severe in etch than they were
in sarge, and I'd rather close this bug, or maybe set it to wishlist
until Julian's idea gets implemented.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)