[m-dev.] Libraries Idea

[Warwick Harvey]

Peter Schachte wrote:
> On Mon, Sep 20, 1999 at 04:44:25PM +1000, Warwick Harvey wrote:
> > With regard to Ralph's proposal, I have a number of concerns, which I think 
> > should be addressed before taking things much further.
> > 
> > 1.  If the idea is to build grades lazily, and a library is missing in the 
> > grade being used, how does the system know in which directory in the search 
> > path the library belongs?
> 
> A config file.
> 
> > 2.  Assuming the system knows in which directory the library should go, how 
> > does it know where to find the source for that library?
> 
> A config file.

Yes, I believe there exists a scheme using config files which would address 
these points to my satisfaction.  ;-)

> > 3.  On a multi-user / shared installation, how does one assure that file 
> > ownership and permissions are appropriate so that (a) anybody can cause a 
> > new grade to be installed, (b) a grade installed by one user can be used by 
> > another, and (c) no user can do malicious things to the installation.
> 
> An suid program?  What do TeX installations do so that generated fonts
> can be shared?  This is basically the same problem.

Unfortunately, it's a sufficiently different problem.  Fonts aren't 
executed.  :-(

The TeX I have installed on my Linux box has the generated font files owned 
by theh person who generated them.  Directories are mode 1777 and files are 
mode 644, so anybody can access the existing fonts or add new ones.  It also 
means you have to "trust" the fonts put there by somebody else, but the 
"worst" that could happen (I believe) is that your document looks screwy 
when you've processed it.  Obviously that doesn't work for files which get 
_executed_ (e.g. libraries), since one cannot afford to trust somebody 
else's executable code in the same way...

Another program I've seen cache generated files in this way is some versions 
of "man".  These run setuid, and cache the processed versions of man pages 
so they don't need to be re-processed if they're used again soon.  I've 
_heard_ that these kinds of systems have a history of security-related 
problems, and thus are somewhat out of favour with the security-conscious.

In any event, I'd be *very* concerned about a setuid solution to this 
problem.  It just seems too likely to be vulnerable to exploitation.

Warwick

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------