From owner-freebsd-hackers Thu May 29 13:43:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA08198 for hackers-outgoing; Thu, 29 May 1997 13:43:43 -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 NAA08190 for ; Thu, 29 May 1997 13:43:40 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA04142; Thu, 29 May 1997 13:40:39 -0700 From: Terry Lambert Message-Id: <199705292040.NAA04142@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: imp@village.org (Warner Losh) Date: Thu, 29 May 1997 13:40:39 -0700 (MST) Cc: terry@lambert.org, dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at May 29, 97 12:27:24 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 > : If the vnode in which the ".." entry is being looked up is > : outside the jail, the lookup should return the jail. This > : is the main chroot() bug in namei(). > > You mistakenly assume there is more than one jail. All you have is > one pointer, not a nesting. So once you reset that pointer and you > have pointers outside the jail, you can still use them. You are assuming that I allow you to fchdir() out of the new jail. 8-). > : Currently, it's possible to store a parent directory for every > : directory in the on disk inode, such that it's possible to determine > : the location of any directory inode in an FS hierarchy, and *know* > : that the current directory is outside the jail, and prohibit reverse > : traversals. That this is not done is an error in the UFS directory > : handling code, so it affects FFS, MFS, LFS, and EXT2FS, etc.. > > Yes, but you have to be careful how you do this. The obvious fix > breaks many traditional uses of chroot. Directories are special > beasts, but in general you can't know if a given file is inside a > chroot area or not due to hard links. "Traditional uses" don't rely on an fchdir() out of scope. Personally, I think root should be able to reset the chroot, either by "fchdir( fd); chroot( ".");", or less dangerously, via an fchroot( fd); > : It should be noted that only relative forward paths would then work > : once outside a jail, so you should still be in the real jail. Any > : absolute paths would fail. > > Once you are outside the jail, you can relative path everything. > etc/passwd works just as well :-) I know; my point was that by blocking relative traversals if you are out of hierarchy, you are saved, because absolute traversal is relative to the jail. > : Probably the best fix is to record the hierarchy, as noted above, and > : then provide an fchroot() that is allowed out of the hierarchy. > > I don't understand this. For root reset without the race condition. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.