Olaf van der Spek <[EMAIL PROTECTED]> 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)
