Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!munnari.oz.au!basser!usage!troy@mr_plod.cbme.unsw.oz
From: troy@mr_plod.cbme.unsw.oz (Troy Rollo)
Newsgroups: comp.sys.apollo
Subject: Re: DM editor as a process
Message-ID: <509@usage.csd.unsw.oz>
Date: 3 Dec 89 06:08:52 GMT
References: <1989Nov29.094555.24366@hellgate.utah.edu>
Sender: news@usage.csd.unsw.oz
Reply-To: troy@mr_plod.cbme.unsw.oz
Lines: 33

From article <1989Nov29.094555.24366@hellgate.utah.edu>, by zeleznik@cs.utah.edu (Mike Zeleznik):

zeleznik> We got around this problem of DM owning the editor in the past with a
zeleznik> small shell script wrapped around the "dmed" program.  

zeleznik> The script simply copied the desired file into /tmp with world write
zeleznik> access, and edited it there.  On exit, it moved the original file to a .bak
zeleznik> version (thus keeping original ACLs), copied the /tmp file back to the
zeleznik> original location, and then set the ACLs on this new file from the .bak
zeleznik> file.  It also had lots of checks to make sure you didn't lose things on
zeleznik> abort or error.

zeleznik> **** Obviously this is NOT secure **** but it does serve the purpose if
zeleznik> security of that sort is not a primary issue.

It could be made to be secure with a slight modification. If each user has 
their own group ID, the editor could change the group owner of the temp file
to the owner of the DM process. Apollo have kindly created an extra ID which
can be used for similar things, the organization ID, so there's really no
excuse for leaving a security hole like that.

Of course it gets better - with extended ACLs you can simply grant access to
the user who owns the display to the file in question... with:

chacl user.%.%=rw file

and remove with:

chacl user.%.%= file 

___________________________________________________________
troy@mr_plod.cbme.unsw.oz.au	Make our greenies useful!
The Resident Fascist		Put them in the army!