Bug#366805: tex-common: Group question for tex files: too difficult IMO
Olaf van der Spek <OvdSpek@LIACS.NL> wrote:
>>> But a 'normal' user doesn't have any idea about what's being asked and
>>> what group should be used.
>> Does that improve when you read it in the context?
>
> I still think it's too hard for normal users.
Could you be more specific? What is hard, what should be improved? If
you don't tell me which ideas are unclear, or which words, or whatever,
I can't improve the text.
>>> Also, a simple enter didn't use the default, although that may be a
>>> bug in the debconf frontend I'm using.
>> What did it choose instead? In the dialog frontend, it always took
>> the
>> default for me. readline doesn't display the default, I guess hitting
>> enter will just take the empty string and give a debconf error message.
>> Other frontends I haven't tried.
>
> I've indeed got readline on this machine.
So there's no problem in tex-common here. Read debconf(7) and install
libterm-readline-gnu-perl, and it will display the defaults. I've only
just learned this from the debconf BTS page...
> Using the group users still violates the user isolation scheme IMO and
> could/should also be considered a security risk.
The whole idea of a shared font cache is a security risk. Restricting
this to a specific group makes the risk a little smaller.
The real fix would be to implement the whole thing differently, for
example with a daemon who does the caching and generates or offers the
files on user request. However, this is complicated, since it would
also need to run on Windows.
> Isn't it possible to create a tex user and have that user (via setuid
> binaries) manage the shared data in a safe way?
Never thought about that. Yes, it seems possible, but it's *not*
trivial. The executables that are called to generate the fonts are
simple shell scripts, and setuid shell scripts aren't possible on Linux
(and you don't want them, anyway). The shell scripts call mf, a real
binary, but this is also meant to be used directly and can't be setuid.
So this would require to rewrite the whole thing in Perl (or whatever,
but there's no Python guy in the Debian TeX Task Force AFAIK), make it
properly parse the common "configuration files" which have shell-syntax,
and be safe (I'm not sure how safe Perl setuid scripts can be). And
this would only solve the problem for systems which know about setuid,
in other words not on Windows. I doubt that upstream would want to go
that way.
On the other hand, deviating from upstream here is a burden, we would
have to port every change in the shell scripts to the Perl scripts.
In summary, I don't think that, after so many years of multiuser
machines with world-writeable font cache directories, it's worth the
effort (especially in these days of decreasing importance of multiuser
machines). Rather we should concentrate on designing the
to-be-implemented kpse library in a way that allows for a daemon.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: