Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!udel!princeton!phoenix!stealth!brnstnd
From: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.sources.d
Subject: There are two separate chroot() issues!
Message-ID: <11141@phoenix.Princeton.EDU>
Date: 28 Oct 89 22:30:47 GMT
References: <DRW.89Oct25234218@fibonacci.math.mit.edu> <1491@crdos1.crd.ge.COM> <1196@atha.AthabascaU.CA>
Sender: news@phoenix.Princeton.EDU
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Distribution: usa
Organization: NYU. (whew!)
Lines: 15

Any user who can execute a chroot() (and who can write a directory on the
same filesystem as /bin/su) can become root. That's the point the original
poster was trying to make; that's why only root is allowed to chroot().

The previous discussion here was on a different issue: *once* a process
(in particular, the unshar process) is stuck inside a chroot(), can it
affect anything outside its sub-filesystem? The answer is obviously no.
(Modulo IPC and network facilities, but that's no problem if you reserve
a userid for the unsharing and if you hide your network libraries. It
wouldn't be funny if processes started dying...)

Yes, chroot() would be a security hole if normal users could use it.
Yes, it's safe to stick an unshar into a chroot() sub-filesystem.

---Dan