Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!ut-emx!mic
From: mic@ut-emx.uucp (Mic Kaczmarczik)
Newsgroups: comp.sys.next
Subject: Re: Postscript
Message-ID: <47941@ut-emx.uucp>
Date: 26 Apr 91 03:34:28 GMT
References: <1991Apr22.211904.8832@ni.umd.edu> <47755@ut-emx.uucp> <51753@nigel.ee.udel.edu>
Organization: UT Austin Computation Center, Unix/VMS Services
Lines: 58

In article <51753@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes:
>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.	 

	I was not advocating or approving the removal of all write access at
	all times; I was pointing out a common application where someone
	concerned about system security and reliability *would* wish to be
	able to disable it completely.  I may not want random print jobs from
	other systems perusing world readable files or creating random files
	on my system, yet may still want to offer printing service. 

>					The root of the problem is that UNIX
>permission bits don't include a set for "network" or "not on this machine".

	Isn't the root of the problem that the Display PostScript server does
	not offer much in the way of authentication?  One you connect to the
	window server, from wherever you are, you have as much (or as little)
	access as any other connection does.  You can write to windows, delete
	windows, freeze the server, what have you, without ever dipping into
	the Unix file system.

	I think the DPS server needs to be more discriminating about who it
	accepts connections from.  I don't want to arbitrarily let anybody
	else on the net poke at my server from another machine, but maybe I do
	want to run remote DPS applications.  As far as I know, as things
	stand now I can't do both at the same time.

>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.)

	I would certainly agree that the UNIX authentication scheme has
	problems in an open, networked environment.  I'm glad to see that
	there are efforts like Kerberos that address the issue of
	network-based authentication and authorization.  How about a DPS
	server that authenticates connections and file opens using Kerberos,
	and then uses your Kerberos credentials on your behalf to open files? 

>--- 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 +=+


-- 
Mic Kaczmarczik			|
Unix/VMS Services		| It's amazing how much ``mature wisdom''
UT Austin Computation Center	| resembles being too tired.
remark@{ccwf,emx,bongo} 1-0251  |      		  The Notebooks of Lazarus Long