Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.sources.d
Subject: Re: Safer unsharing
Message-ID: <1008@crdos1.crd.ge.COM>
Date: 11 Oct 89 17:08:50 GMT
References: <15018@bloom-beacon.MIT.EDU>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: GE Corp R&D Center
Lines: 35

In <15018@bloom-beacon.MIT.EDU>, drw@math.mit.edu (Dale R. Worley) writes:
|	[ run /bin/sh under chroot or as limited user ]
|  
|  Why doesn't this work?

  It does. The complaint is that you need to be root to run the chroot.
Also, the environment has to be complete enough to include all of the
things which a shar might reasonably use, like cat, sed, sum, col, test
(and [), etc.

  The other alternative you mention, a userid just for unshar, is much
easier. I created such an id on my system, and a little program to do
the su to it and execute the script. It then scans for files and
directories which are (a) setuid, (b) not owned by the special user, or
(c) executable and world or group write.

  Either of these are a pain to set up and use. If there were a better
way to pass files around shar would have died long ago. Since everyone
has /bin/sh the true shar format is very convenient.

  For SysV users a SysV /bin/sh (that's a lot of us these days) a
directory may be created which holds a few common commands, then the
restricted shell with a limited path may be run, something like:
	PATH=/limitedbin; readonly PATH
	set -r
	. sharfile

  I make no claim that this is perfect, just quick and easy to use, and
a lot better than nothing. A quick scan through the shar for filenames
with leading / is advised, too.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon