Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!olivea!genie!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.sys.next
Subject: Re: Postscript
Message-ID: <51753@nigel.ee.udel.edu>
Date: 24 Apr 91 15:22:37 GMT
References: <1991Apr22.212326.26982@csusac.csus.edu> <1991Apr22.211904.8832@ni.umd.edu> <47755@ut-emx.uucp>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 44
Nntp-Posting-Host: estelle.ee.udel.edu

In article <47755@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes:
>	The more general case is a pain, since there are some times you
>	need to disable *all* write access to files (e.g. for print jobs
>	submitted from systems you allow to print on your printer but 
>	nothing else).  

No, no, no, no.  All you have to do is disable writing to files you don't
want the postscript code to write to. The root of the problem is that UNIX
permission bits don't include a set for "network" or "not on this machine".
Because of the fact that UNIX permissions have not kept up with the rest of
the OS, I think anything based on user ID or other UNIX-style permissions
are going to be "the Wrong Thing."  (Of course, the "Right Thing" would be
to add a forth rwx set for "not on this machine" and a fifth for "not on
this autonomous network" which would both default to ---, which would
also cure anon-FTP and UUCP problems. Yea, good luck.)

The particular solution in the case of PostScript could be either

1) Allow writing to files only in certain directories, much like /uucppublic.
In this way, you always know where to look for files and you can get them out
of the way before running something else which might clobber these files.

2) Allow writing only to files which have been created within the current
postscript context (or smaller).  That is, do not allow *over*writing of
files. I don't imagine it is especially common that applications want
to append to files already existant, but I may be wrong.

Since the postscript interpreter itself is presumedly protected, you could
get as fancy as you wanted with proper changes, including using the sticky
bit and stuff like that.  The most fancy solution might be this:

Have a subdirectory for each UID, say /usr/spool/postscriptout/me and so
on. All output to a particular PostScript device (like OUT:) goes there,
and no other device is writable. If the sticky bit is set on the dir,
then only creating new files is permitted, otherwise overwriting old
files in this dir only is permitted.   Doesn't seem too hard to implement.

		   -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
     +=+=+ My time is very valuable, but unfortunately only to me +=+=+
+=+ Nails work better than screws, when both are driven with screwdrivers +=+