[Cc'ing to -devel]
> Package: tetex-base
> Version: 0.9.990406-1
>
> Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644.
> Therefore all font generation operations get an error:
>
> /usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable.
>
> Changing it to mode 666 works around the problem, but the right thing
> would be to make mktexupd setgid to some group (daemon?) and make
> /var/spool/texmf/ls-R writable by that group. Possibly the same thing
> should be done to the subdirectories of /var/spool/texmf, mode 1777
> can be problematic.
You are correct. A fully working solution which closes the security
holes is not straightforward, though. I am currently working on a
project to solve this problem. In the meantime though, note that the
font _is_ generated and stored, will be found by kpathsea on the next
occasion that it is needed, and will be written into the ls-R file the
next time the tetex cron job runs.
My current state of progress is:
- Working Perl Kpathsea interface and Kpathsea module (although they
are labelled as alpha, there are some minor bugs apparently and
the Makefiles need cleaning up). You can download it from
http://www.debian.org/~jdg.
- I have rewritten all of the mktex scripts in Perl except for
mktex{mf,tfm,pk}. (You might say, "Huh? But that's all of them!"
But this means that I have dealt with mktex.opt, mktexnam,
mktexnam.opt, mktexdir, mktexdir.opt, mktexupd and mktexlsr. Just
the three last ones to go.) Unfortunately, these are currently on
paper only; you can have a photocopy of them if you really desire ;)
Still to go:
- At present, I am working on making the Perl scripts behave
identically (modulo bugs) to the shell script counterparts. When
this is working, I fully intend to introduce variant behaviour if
the script is running setuid. We need the scripts to be setuid
tex if they are to be secure, as otherwise, the owner of the
process will still own any font files created, which is Not Good.
Then the writeable font trees would be owned by tex, mode 755, and
ls-R would be owned by tex with mode 644.
- 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. The mktex{mf,tfm,pk} scripts should
do the following if they are running setuid (and do the same as
present if not):
. In a child process, drop any privileges and check the
locations of the files which would need to be created (by
calling mktexnam). Report back to the parent process.
. In the parent process, compare the results against the value of
SYSTEXMF obtained from the system texmf.cnf files, having
cleared (but saved) any environment variables. If the location
which would be used is not within the SYSTEXMF trees, then drop
privileges, reinstate the old environment and create the font.
Since the process is now running as the user with no
privileges, any nasty settings in their personal texmf.cnf or
environment will be ignored.
. Otherwise, we continue with privileges and a sanitised
environment to figure out where *we* would like to place the
created fonts by calling mktexnam again. If it is not in one
of the recognised places (SYSTEXMF, VARFONTS), give up.
Otherwise, go ahead and create the font.
- Issues which need to be addressed for this to work:
. mktexnam currently makes assumptions about the location of a
font based on the writeability of a directory. We must ensure
that these assumptions are correct in this scheme.
. We must be very careful to fork a child process to do the font
creation *before* invoking any of the Kpathsea routines, as the
texmf.cnf files cannot be reinitialised easily. A better
solution may well be to have mktex{mf,tfm,pk} be setuid C
wrappers which call the non-setuid mktex{mf,tfm,pk}.pl scripts;
then they can simply exec another copy of themselves and load
the Kpathsea library afresh. (This also avoids people needing
to have suidperl around if they don't want it.) Doing this
properly is probably a bit painful (will probably use parts of
Kpathsea's proginit.c to get the right location of the mktex
scripts).
. This sound like a lot of computational work, and that it will
be a lot slower than the present system, but since the ls-R
databases will need loading only a handful of times, this
should turn out to be much faster.
Comments appreciated!
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
