Date: Thu, 29 May 1997 13:35:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rb@gid.co.uk (Bob Bishop) Cc: imp@village.org, dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG, terry@lambert.org Subject: Re: Correct way to chroot for shell account users? Message-ID: <199705292035.NAA04127@phaeton.artisoft.com> In-Reply-To: <l03020900afb38f29f0df@[194.32.164.2]> from "Bob Bishop" at May 29, 97 08:56:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705292035.NAA04127>