From owner-freebsd-hackers Thu May 29 13:40:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA08034 for hackers-outgoing; Thu, 29 May 1997 13:40:09 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA08021 for ; Thu, 29 May 1997 13:40:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA04127; Thu, 29 May 1997 13:35:54 -0700 From: Terry Lambert Message-Id: <199705292035.NAA04127@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: rb@gid.co.uk (Bob Bishop) Date: Thu, 29 May 1997 13:35:54 -0700 (MST) Cc: imp@village.org, dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG, terry@lambert.org In-Reply-To: from "Bob Bishop" at May 29, 97 08:56:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm sure I'm being desperately naive here, but isn't it sufficient for > safety to make chroot(2) a successful no-op unless / is really / (ie the > process isn't chrooted already)? This ruins a particular croosbuild environment which I personally find convenient. 8-(. But yes, that's the *most* trivial fix. The fix will fail (or become more difficult) if the default root is set and inherited, and the "NULL" token value for "not chroot'ed" goes away. Better to traverse up from the target, and if it's not in the cage, reject it. I prefer storing the parent in the inode so a removed current directory doesn't cause problems with this check, but that's just a matter of personal preference. You could traverse the cache (or fault the entries) as with the getcwd() approach just as easily. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.