[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#37606: /var/spool/texmf/ls-R unwritable



On Thu, 13 May 1999 11:25:10 +0100 (BST), Julian Gilbey wrote:
>[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.

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.

zw


Reply to: