From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 03:48:38 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5121065675 for ; Wed, 18 Jun 2008 03:48:38 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9B93E8FC1F for ; Wed, 18 Jun 2008 03:48:38 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from glorfindel.gritton.org (c-76-27-80-223.hsd1.ut.comcast.net [76.27.80.223]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5I3mbdF073113 for ; Tue, 17 Jun 2008 21:48:37 -0600 (MDT) Message-ID: <48588595.7020709@gritton.org> Date: Tue, 17 Jun 2008 21:48:37 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Subject: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 03:48:39 -0000 Like everything I have to say about the V_* issue, perhaps this doesn't apply to the vnet stuff. But to the two symbols I currently care about, hostname and rootvnode, locking is a problem. Current kernel code plays fast and loose with both these symbols. Check out getcredhostname for example: void getcredhostname(struct ucred *cred, char *buf, size_t size) { struct prison *pr; pr = cred->cr_prison; if (pr != &prison0) { mtx_lock(&pr->pr_mtx); strlcpy(buf, (pr->pr_flags & PR_NOHOST) ? hostname : pr->pr_host, size); mtx_unlock(&pr->pr_mtx); } else strlcpy(buf, hostname, size); } In the prison case, it nicely locks the prison record. But for the global hostname, it just copies it. The hostname sysctl is no better about setting it. And rootvnode is referred to all over the place without any sort of lock - pretty safe since it's not expected to change (though it theoretically can). This same no-locking assumption seems to be going on with V_hostname. But now this macro applies not only to the "real" hostname but to the "virtual" one as well - no locking the vimage record. As I try to add a similar macro to my new jail framework, I find I can't. Instead of a mere variable redirection, I need to lock-copy-unlock much like getcredhostname does. Luckily, much hostname access is already jail-aware. But anything using the "real" hostname should have the same locking on prison0. Perhaps not wholly necessary since it's just a string that we know will always have a null byte at the end of the buffer, but still good form and unknown prevention. And in the case of actually virtual hostnames, it's essential since they'll be changing from fixed arrays in struct prison into pointers that may be freed. Rootvnode is a stickier problem. There's much more code that refers to it, and it's a more essential part of the system. I don't relish digging in everywhere and changing the whole rootvnode paradigm with locking. So instead my solution is to make the jail "path" parameter (and thus root vnode) set-once. So as long as the V_rootvnode is taken from a context that will remain for the duration of its use (curthread is a good bet), it will be safe to access it without locks. In particular, the real rootvnode that lives at prison0 isn't going anywhere. So in summary: I won't use V_hostname (or G_hostname), opting for explicit locking. I will V_rootvnode (and perhaps G_rootvnode). All the other network-related V_stuff may deserve a look, but it out of my purview. - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 06:40:06 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C055010656A9 for ; Wed, 18 Jun 2008 06:40:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id A4D218FC28 for ; Wed, 18 Jun 2008 06:40:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 4D2222447; Tue, 17 Jun 2008 23:40:06 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 020882D6006; Tue, 17 Jun 2008 23:40:05 -0700 (PDT) Message-ID: <4858ADCC.1050909@elischer.org> Date: Tue, 17 Jun 2008 23:40:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: James Gritton References: <48588595.7020709@gritton.org> In-Reply-To: <48588595.7020709@gritton.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 06:40:06 -0000 James Gritton wrote: > Like everything I have to say about the V_* issue, perhaps this doesn't > apply to the vnet stuff. But to the two symbols I currently care about, > hostname and rootvnode, locking is a problem. > yes and I for one have probably not thought enough about it. > Current kernel code plays fast and loose with both these symbols. Check > out getcredhostname for example: > > void > getcredhostname(struct ucred *cred, char *buf, size_t size) > { > struct prison *pr; > > pr = cred->cr_prison; > if (pr != &prison0) { > mtx_lock(&pr->pr_mtx); > strlcpy(buf, (pr->pr_flags & PR_NOHOST) > ? hostname : pr->pr_host, size); > mtx_unlock(&pr->pr_mtx); > } else > strlcpy(buf, hostname, size); > } > > In the prison case, it nicely locks the prison record. But for the > global hostname, it just copies it. The hostname sysctl is no better > about setting it. And rootvnode is referred to all over the place > without any sort of lock - pretty safe since it's not expected to change > (though it theoretically can). I'm not sure there is much of a problem because the hostname associated with a virtual machine is a fixed array of bytes. it is true that one might be able (though unlikely) to get half of one hostname and half of another but you will never get invalid memory.. I think that the only readers of the hostname in a vm are processes in that VM so the VM is not going anywhere and thus the hostname is not going anywhere.. > > This same no-locking assumption seems to be going on with V_hostname. > But now this macro applies not only to the "real" hostname but to the > "virtual" one as well - no locking the vimage record. As I try to add a > similar macro to my new jail framework, I find I can't. Instead of a > mere variable redirection, I need to lock-copy-unlock much like > getcredhostname does. Luckily, much hostname access is already > jail-aware. But anything using the "real" hostname should have the same > locking on prison0. Perhaps not wholly necessary since it's just a > string that we know will always have a null byte at the end of the > buffer, but still good form and unknown prevention. And in the case of > actually virtual hostnames, it's essential since they'll be changing > from fixed arrays in struct prison into pointers that may be freed. I think in the vimage code it is not freeable unless the vimage is freed and in that case there is no-one to read the string. vimage0 is of course not going away under any situation. > > Rootvnode is a stickier problem. There's much more code that refers to > it, and it's a more essential part of the system. I don't relish > digging in everywhere and changing the whole rootvnode paradigm with > locking. So instead my solution is to make the jail "path" parameter > (and thus root vnode) set-once. So as long as the V_rootvnode is taken > from a context that will remain for the duration of its use (curthread > is a good bet), it will be safe to access it without locks. In > particular, the real rootvnode that lives at prison0 isn't going anywhere. teh man page for vimage(8) says for the chroot parameter: chroot Set the chroot directory for the virtual image. All new processes spawned into the target virtual image using the vimage command will be initially chrooted to that directory. This parameter can be changed only when no processes are running within the target virtual image. Note that it is not required to have a chrooted environment for a virtual image operate, which is also the default behavior. so the croot is fixed unless there is no-one using it. > > So in summary: > > I won't use V_hostname (or G_hostname), opting for explicit locking. I'm not sure you need this. > > I will V_rootvnode (and perhaps G_rootvnode). > > All the other network-related V_stuff may deserve a look, but it out of > my purview. > > - Jamie > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 14:40:28 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B2B1065671 for ; Wed, 18 Jun 2008 14:40:28 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id F00EF8FC26 for ; Wed, 18 Jun 2008 14:40:27 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 3345C9B64F; Wed, 18 Jun 2008 16:40:25 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.110] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 4BCB29B645; Wed, 18 Jun 2008 16:40:24 +0200 (CEST) From: Marko Zec To: freebsd-virtualization@freebsd.org Date: Wed, 18 Jun 2008 16:19:06 +0200 User-Agent: KMail/1.9.7 References: <48588595.7020709@gritton.org> In-Reply-To: <48588595.7020709@gritton.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181619.07026.zec@icir.org> Cc: Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 14:40:28 -0000 On Wednesday 18 June 2008 05:48:37 James Gritton wrote: > Like everything I have to say about the V_* issue, perhaps this > doesn't apply to the vnet stuff. But to the two symbols I currently > care about, hostname and rootvnode, locking is a problem. You are most probably right about the current code not sufficiently protecting the "hostname" global from concurrent access, but I don't see how V_ macroization / virtualization adds or changes anything to this particular issue. The same goes for virtualizing the networking state - if there is a locking issue in a newtorking subsystem, virtualization should not make such issues any more or less pronounced. That doesn't mean we shouldn't be looking into solving such issues, but I'd prefer to decouple such efforts from the initial push for virtualizing the networking stack, which I think should keep the changes to existing subsystem's program logic / flow to the absolute minimum. Marko > Current kernel code plays fast and loose with both these symbols. > Check out getcredhostname for example: > > void > getcredhostname(struct ucred *cred, char *buf, size_t size) > { > struct prison *pr; > > pr = cred->cr_prison; > if (pr != &prison0) { > mtx_lock(&pr->pr_mtx); > strlcpy(buf, (pr->pr_flags & PR_NOHOST) > ? hostname : pr->pr_host, size); > mtx_unlock(&pr->pr_mtx); > } else > strlcpy(buf, hostname, size); > } > > In the prison case, it nicely locks the prison record. But for the > global hostname, it just copies it. The hostname sysctl is no better > about setting it. And rootvnode is referred to all over the place > without any sort of lock - pretty safe since it's not expected to > change (though it theoretically can). > > This same no-locking assumption seems to be going on with V_hostname. > But now this macro applies not only to the "real" hostname but to the > "virtual" one as well - no locking the vimage record. As I try to > add a similar macro to my new jail framework, I find I can't. > Instead of a mere variable redirection, I need to lock-copy-unlock > much like getcredhostname does. Luckily, much hostname access is > already jail-aware. But anything using the "real" hostname should > have the same locking on prison0. Perhaps not wholly necessary since > it's just a string that we know will always have a null byte at the > end of the buffer, but still good form and unknown prevention. And > in the case of actually virtual hostnames, it's essential since > they'll be changing from fixed arrays in struct prison into pointers > that may be freed. > > Rootvnode is a stickier problem. There's much more code that refers > to it, and it's a more essential part of the system. I don't relish > digging in everywhere and changing the whole rootvnode paradigm with > locking. So instead my solution is to make the jail "path" parameter > (and thus root vnode) set-once. So as long as the V_rootvnode is > taken from a context that will remain for the duration of its use > (curthread is a good bet), it will be safe to access it without > locks. In particular, the real rootvnode that lives at prison0 isn't > going anywhere. > > So in summary: > > I won't use V_hostname (or G_hostname), opting for explicit locking. > > I will V_rootvnode (and perhaps G_rootvnode). > > All the other network-related V_stuff may deserve a look, but it out > of my purview. > > - Jamie > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 15:20:20 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F4451065670 for ; Wed, 18 Jun 2008 15:20:20 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 62C908FC2D for ; Wed, 18 Jun 2008 15:20:20 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IFKJ92000339; Wed, 18 Jun 2008 09:20:19 -0600 (MDT) Message-ID: <485927AD.8010204@gritton.org> Date: Wed, 18 Jun 2008 09:20:13 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <200806181619.07026.zec@icir.org> In-Reply-To: <200806181619.07026.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 15:20:20 -0000 Marko Zec wrote: > You are most probably right about the current code not sufficiently > protecting the "hostname" global from concurrent access, but I don't > see how V_ macroization / virtualization adds or changes anything to > this particular issue. The change is that with the virtual hostname, I want to have the locking that is currently lacking. As that locking would be in a jail context, it doesn't make sense to go use these virtual-variable macros when the "jailness" of it is explicitly exposed anyway. > The same goes for virtualizing the networking > state - if there is a locking issue in a newtorking subsystem, > virtualization should not make such issues any more or less pronounced. I suspect most, perhaps all, of the networking variables will work with their own locking, especially if the locks themselves are part of a virtualized structure. - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 15:56:46 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47FFA1065679 for ; Wed, 18 Jun 2008 15:56:46 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id E23678FC15 for ; Wed, 18 Jun 2008 15:56:45 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IFuhuX001681; Wed, 18 Jun 2008 09:56:44 -0600 (MDT) Message-ID: <48593036.60502@gritton.org> Date: Wed, 18 Jun 2008 09:56:38 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> In-Reply-To: <4858ADCC.1050909@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: Julian Elischer Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 15:56:46 -0000 Julian Elischer wrote: > I'm not sure there is much of a problem because the hostname associated with a virtual machine is a fixed array of bytes. > > it is true that one might be able (though unlikely) to get half of one hostname and half of another but you will never get invalid memory.. > > I think that the only readers of the hostname in a vm are processes in that VM so the VM is not going anywhere and thus the hostname is not going anywhere.. This is true of current jail code, and of vimage. But one of the points made in the developer summit was that a jail should be able to virtualize some things and not others. The was really meant about modules, but it made sense to me that there should also be the option not to virtualize the non-module bits, i.e. perhaps have a jail that only had the vnet stuff but kept, for example, the same hostname as its parent. And I don't mean just inheriting the current hostname, but making it totally non-virtual so any change to the parent is reflected. I'm implementing this by replacing that fixed array with a pointer that may well be freed. That makes the concurrency issues less trivial than just the possibility of copying part of one hostname and not part of another. Now perhaps it would be better to keep the fixed array, making reading the virtual hostname safe, and complicating the setting issue (I'd have to set potentially multiple jail records). This makes sense, as setting is much less common, and is in line with a similar strategy I have for the securelevel. Even with that though, the mechanism is in place for safely reading a hostname (i.e. getcredhostname) and is just not universally used. Might as well clean that up. > teh man page for vimage(8) says for the chroot parameter: > > chroot > Set the chroot directory for the virtual image. All new processes > spawned into the target virtual image using the vimage command > will be initially chrooted to that directory. This parameter can > be changed only when no processes are running within the target > virtual image. Note that it is not required to have a chrooted > environment for a virtual image operate, which is also the > default behavior. > > so the croot is fixed unless there is no-one using it. That's a good idea - more flexible than my current strategy of only allowing setting the path on jail creation, but still not messing up current jails. And I can continue to ignore the locking implications of rootvnode. - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 15:55:04 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E65881065673; Wed, 18 Jun 2008 15:55:04 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0B48FC6E; Wed, 18 Jun 2008 15:55:04 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id 1CEC6275F483; Wed, 18 Jun 2008 17:23:26 +0200 (CEST) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 6E7083F638A; Wed, 18 Jun 2008 17:23:24 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 32DE03F6156; Wed, 18 Jun 2008 17:23:23 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id E4BB89B497; Wed, 18 Jun 2008 15:19:11 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id DF1444089; Wed, 18 Jun 2008 17:19:11 +0200 (CEST) Date: Wed, 18 Jun 2008 17:19:11 +0200 From: Jeremie Le Hen To: Julian Elischer Message-ID: <20080618151911.GB46885@obiwan.tataz.chchile.org> References: <484CC690.9020303@elischer.org> <48536C9A.8020801@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48536C9A.8020801@elischer.org> User-Agent: Mutt/1.5.15 (2007-04-06) X-Mailman-Approved-At: Wed, 18 Jun 2008 16:00:30 +0000 Cc: Marko Zec , FreeBSD Current , freebsd-virtualization@freebsd.org Subject: Re: Vimage headsup.. revised. X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 15:55:05 -0000 Hi all, On Sat, Jun 14, 2008 at 12:00:42AM -0700, Julian Elischer wrote: > Also some interesting work has turned up that may be relevent > at the later stages WRT cobining vimage and jails. Is it possible to follow this work/discussion somewhere? Besides, I'd like to join the freebsd-virtualization@ mailing-list, but I can't see it in Mailman. Is it a private one? Thanks and regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 16:19:12 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6964106564A for ; Wed, 18 Jun 2008 16:19:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id B6D128FC17 for ; Wed, 18 Jun 2008 16:19:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 6F0592425; Wed, 18 Jun 2008 09:19:12 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 29CA62D6010; Wed, 18 Jun 2008 09:19:12 -0700 (PDT) Message-ID: <48593586.9040600@elischer.org> Date: Wed, 18 Jun 2008 09:19:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: James Gritton References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> <48593036.60502@gritton.org> In-Reply-To: <48593036.60502@gritton.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:19:13 -0000 James Gritton wrote: > Julian Elischer wrote: > > > I'm not sure there is much of a problem because the hostname > associated with a virtual machine is a fixed array of bytes. > > > > it is true that one might be able (though unlikely) to get half of > one hostname and half of another but you will never get invalid memory.. > > > > I think that the only readers of the hostname in a vm are processes > in that VM so the VM is not going anywhere and thus the hostname is not > going anywhere.. > > This is true of current jail code, and of vimage. But one of the > points made in the developer summit was that a jail should be able to > virtualize some things and not others. The was really meant about > modules, but it made sense to me that there should also be the option > not to virtualize the non-module bits, i.e. perhaps have a jail that > only had the vnet stuff but kept, for example, the same hostname as > its parent. And I don't mean just inheriting the current hostname, > but making it totally non-virtual so any change to the parent is > reflected. since vimage in hierarchical, and all hostnames are virualised, then the hostname you use is either yours or that of a parent vimage. either way, since you can not remove a vimage while it has children vimages, the logic still applies. > > I'm implementing this by replacing that fixed array with a pointer > that may well be freed. That makes the concurrency issues less > trivial than just the possibility of copying part of one hostname and > not part of another. Now perhaps it would be better to keep the fixed > array, making reading the virtual hostname safe, and complicating the > setting issue (I'd have to set potentially multiple jail records). > This makes sense, as setting is much less common, and is in line with > a similar strategy I have for the securelevel. Even with that though, > the mechanism is in place for safely reading a hostname (i.e. > getcredhostname) and is just not universally used. Might as well > clean that up. well if you want to do that then that is a separate thing but the reason is not because of what vimage is doing with hostname :-) > > > > the man page for vimage(8) says for the chroot parameter: > > > > chroot > > Set the chroot directory for the virtual image. All new processes > > spawned into the target virtual image using the vimage command > > will be initially chrooted to that directory. This parameter can > > be changed only when no processes are running within the target > > virtual image. Note that it is not required to have a chrooted > > environment for a virtual image operate, which is also the > > default behavior. > > > > so the croot is fixed unless there is no-one using it. > > That's a good idea - more flexible than my current strategy of only > allowing setting the path on jail creation, but still not messing up > current jails. And I can continue to ignore the locking implications > of rootvnode. Note that one could also read "or children images" I think in some of these checks.. > > - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 16:21:13 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E05F01065670 for ; Wed, 18 Jun 2008 16:21:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id C15F28FC34 for ; Wed, 18 Jun 2008 16:21:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 77C492433; Wed, 18 Jun 2008 09:21:13 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id EB8112D6013; Wed, 18 Jun 2008 09:21:12 -0700 (PDT) Message-ID: <485935FF.8040308@elischer.org> Date: Wed, 18 Jun 2008 09:21:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jeremie Le Hen References: <484CC690.9020303@elischer.org> <48536C9A.8020801@elischer.org> <20080618151911.GB46885@obiwan.tataz.chchile.org> In-Reply-To: <20080618151911.GB46885@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , FreeBSD Current , freebsd-virtualization@freebsd.org Subject: Re: Vimage headsup.. revised. X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:21:14 -0000 Jeremie Le Hen wrote: > Hi all, > > On Sat, Jun 14, 2008 at 12:00:42AM -0700, Julian Elischer wrote: >> Also some interesting work has turned up that may be relevent >> at the later stages WRT cobining vimage and jails. > > Is it possible to follow this work/discussion somewhere? > > Besides, I'd like to join the freebsd-virtualization@ mailing-list, but > I can't see it in Mailman. Is it a private one? > > Thanks and regards, I've asked teh admins to get the virtualization mailing list archived and more generally available.. From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:10:50 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A71911065678 for ; Wed, 18 Jun 2008 19:10:50 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA388FC2A for ; Wed, 18 Jun 2008 19:10:49 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IJAlEG009060; Wed, 18 Jun 2008 13:10:48 -0600 (MDT) Message-ID: <48595DB2.3030005@gritton.org> Date: Wed, 18 Jun 2008 13:10:42 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> <48593036.60502@gritton.org> <48593586.9040600@elischer.org> In-Reply-To: <48593586.9040600@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: Julian Elischer Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 19:10:50 -0000 Julian Elischer wrote: >>> the man page for vimage(8) says for the chroot parameter: >>> >>> chroot >>> Set the chroot directory for the virtual image. All new processes >>> spawned into the target virtual image using the vimage command >>> will be initially chrooted to that directory. This parameter can >>> be changed only when no processes are running within the target >>> virtual image. Note that it is not required to have a chrooted >>> environment for a virtual image operate, which is also the >>> default behavior. >>> >>> so the croot is fixed unless there is no-one using it. > > Note that one could also read "or children images" I think in some of these checks.. The situation with setting the chroot path becomes more complicated the more I look at it. If I replicate the vimage behavior of being able to set jails more than one level below the current jail (i.e. create "foo.bar.baz" which would be placed under the current "foo.bar"), then there's not necessarily a connection between place in the prison hierarchy and the file hierarchy. I could create jail "foo.bar" rooted at /home/foo/bar and then create "foo.bar.baz" rooted at /home/baz. That's kind of nonintuitive. Or perhaps I could restrict the chroot pathname lookup not to the caller's root, but to the parent jail's root. But pathnames that are looked up with something other that the root of the process doing the looking is also rather counterintuitive. And then there's the possibility of changing the root path. Suppose I have "foo" at /home/foo and "foo.bar" at home.bar. If I then change foo's home to /jail/foo, does foo.bar's jail likewise change to /home/foo/bar? What if /jail/foo/bar doesn't exist? Should the whole thing fail, or would I have foo now at /jail/foo and foo.bar at /home/foo/bar? I could just not recursively re-root child jails when I change a chroot path - except I still should if foo.bar isn't separately chrooted and also lives at /home/foo. Making things even worse, jail allows relative chroot paths. Those saved pathnames (used for prison_canseemount and prison_enforce_statfs) are totally useless when the erstwhile current directory is unknown. I'd just not allow them, but the current behavior of rendering all mount points essentially invisible under such circumstances seems reasonable. But there'd certainly be no way to relate a relative chroot pathname to its place in any parent jails. The upshot of all this is that for now, I'm sticking with only allowing the path to be set when a jail is created. The vimage implementation of all this seems to consist entirely of the quoted man page, so I can't just go there for answers. - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:21:17 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B635C106564A for ; Wed, 18 Jun 2008 19:21:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 93A688FC19 for ; Wed, 18 Jun 2008 19:21:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 772022383; Wed, 18 Jun 2008 12:21:17 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id CBAF22D703C; Wed, 18 Jun 2008 12:21:16 -0700 (PDT) Message-ID: <48596033.5070906@elischer.org> Date: Wed, 18 Jun 2008 12:21:23 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: James Gritton References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> <48593036.60502@gritton.org> <48593586.9040600@elischer.org> <48595DB2.3030005@gritton.org> In-Reply-To: <48595DB2.3030005@gritton.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 19:21:17 -0000 James Gritton wrote: > Julian Elischer wrote: > > >>> the man page for vimage(8) says for the chroot parameter: > >>> > >>> chroot > >>> Set the chroot directory for the virtual image. All new processes > >>> spawned into the target virtual image using the vimage command > >>> will be initially chrooted to that directory. This parameter can > >>> be changed only when no processes are running within the target > >>> virtual image. Note that it is not required to have a chrooted > >>> environment for a virtual image operate, which is also the > >>> default behavior. > >>> > >>> so the croot is fixed unless there is no-one using it. > > > > Note that one could also read "or children images" I think in some of > these checks.. > > > The situation with setting the chroot path becomes more complicated > the more I look at it. If I replicate the vimage behavior of being > able to set jails more than one level below the current jail > (i.e. create "foo.bar.baz" which would be placed under the current > "foo.bar"), then there's not necessarily a connection between place in > the prison hierarchy and the file hierarchy. I could create jail > "foo.bar" rooted at /home/foo/bar and then create "foo.bar.baz" rooted > at /home/baz. That's kind of nonintuitive. Or perhaps I could > restrict the chroot pathname lookup not to the caller's root, but to > the parent jail's root. But pathnames that are looked up with > something other that the root of the process doing the looking is also > rather counterintuitive. > > And then there's the possibility of changing the root path. Suppose I > have "foo" at /home/foo and "foo.bar" at home.bar. If I then change > foo's home to /jail/foo, does foo.bar's jail likewise change to > /home/foo/bar? What if /jail/foo/bar doesn't exist? Should the whole > thing fail, or would I have foo now at /jail/foo and foo.bar at > /home/foo/bar? I could just not recursively re-root child jails when > I change a chroot path - except I still should if foo.bar isn't > separately chrooted and also lives at /home/foo. I beieve you can not change a chroot if there are 1/ running processes 2/ children vimages.. effectively this means that you really only have one chance to reparent a vimage, and that is right after you have created it. Once it has children (either processes or vimages), you have "fixed it. I do think that the chroot path needs to be expressed when creating it in the terms of the parent vimage. If no chroot is specified then it gets what its parent had.. I have not actually looked (yet) to see what Marko has done here.. (wanders off to do so) > > Making things even worse, jail allows relative chroot paths. Those > saved pathnames (used for prison_canseemount and > prison_enforce_statfs) are totally useless when the erstwhile current > directory is unknown. I'd just not allow them, but the current > behavior of rendering all mount points essentially invisible under > such circumstances seems reasonable. But there'd certainly be no way > to relate a relative chroot pathname to its place in any parent jails. > > The upshot of all this is that for now, I'm sticking with only > allowing the path to be set when a jail is created. > > The vimage implementation of all this seems to consist entirely of the > quoted man page, so I can't just go there for answers. > > - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:40:44 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7240F1065673 for ; Wed, 18 Jun 2008 19:40:44 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id ED1D98FC16 for ; Wed, 18 Jun 2008 19:40:43 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id CF0079B649; Wed, 18 Jun 2008 21:40:42 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.112] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 782E49B64F; Wed, 18 Jun 2008 21:40:40 +0200 (CEST) From: Marko Zec To: freebsd-virtualization@freebsd.org Date: Wed, 18 Jun 2008 21:40:22 +0200 User-Agent: KMail/1.9.7 References: <48588595.7020709@gritton.org> <48593586.9040600@elischer.org> <48595DB2.3030005@gritton.org> In-Reply-To: <48595DB2.3030005@gritton.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806182140.23123.zec@icir.org> Cc: Julian Elischer Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 19:40:44 -0000 On Wednesday 18 June 2008 21:10:42 James Gritton wrote: > Julian Elischer wrote: > >>> the man page for vimage(8) says for the chroot parameter: > >>> > >>> chroot > >>> Set the chroot directory for the virtual image. All new > >>> processes spawned into the target virtual image using the vimage > >>> command will be initially chrooted to that directory. This > >>> parameter can be changed only when no processes are running > >>> within the target virtual image. Note that it is not required to > >>> have a chrooted environment for a virtual image operate, which > >>> is also the default behavior. > >>> > >>> so the croot is fixed unless there is no-one using it. > > > > Note that one could also read "or children images" I think in some > > of > > these checks.. > > > The situation with setting the chroot path becomes more complicated > the more I look at it. If I replicate the vimage behavior of being > able to set jails more than one level below the current jail > (i.e. create "foo.bar.baz" which would be placed under the current > "foo.bar"), then there's not necessarily a connection between place > in the prison hierarchy and the file hierarchy. I could create jail > "foo.bar" rooted at /home/foo/bar and then create "foo.bar.baz" > rooted at /home/baz. That's kind of nonintuitive. True. Chrooting "foo.bar.baz" at absolute path of /home/foo/bar/home/baz could be a more logical action. > Or perhaps I > could restrict the chroot pathname lookup not to the caller's root, > but to the parent jail's root. But pathnames that are looked up with > something other that the root of the process doing the looking is > also rather counterintuitive. > > And then there's the possibility of changing the root path. Suppose > I have "foo" at /home/foo and "foo.bar" at home.bar. If I then > change foo's home to /jail/foo, does foo.bar's jail likewise change > to /home/foo/bar? What if /jail/foo/bar doesn't exist? Should the > whole thing fail, or would I have foo now at /jail/foo and foo.bar at > /home/foo/bar? I could just not recursively re-root child jails when > I change a chroot path - except I still should if foo.bar isn't > separately chrooted and also lives at /home/foo. > > Making things even worse, jail allows relative chroot paths. Those > saved pathnames (used for prison_canseemount and > prison_enforce_statfs) are totally useless when the erstwhile current > directory is unknown. I'd just not allow them, but the current > behavior of rendering all mount points essentially invisible under > such circumstances seems reasonable. But there'd certainly be no way > to relate a relative chroot pathname to its place in any parent > jails. > > The upshot of all this is that for now, I'm sticking with only > allowing the path to be set when a jail is created. > > The vimage implementation of all this seems to consist entirely of > the quoted man page, so I can't just go there for answers. vimage(8) simply invokes chroot(2) to the target directory (stored a plaintext string in the kernel) before spawning a new process inside the target VM. Obviously such an approach has served only as a proof of concept hack (though there's some anecdotal evidence some ISPs have been making money using precisely such vimage implementation on FreeBSD 4.11). Hence, don't feel constrained by the legacy of such kludges, and feel free to propose better alternatives. The only thing I'd like to have as an option is to be able to spawn a new process in the target VM _without_ making it chrooted... Marko From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:46:45 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED6FF1065679 for ; Wed, 18 Jun 2008 19:46:45 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 615408FC1A for ; Wed, 18 Jun 2008 19:46:45 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IJkie5010026; Wed, 18 Jun 2008 13:46:44 -0600 (MDT) Message-ID: <4859661E.9070502@gritton.org> Date: Wed, 18 Jun 2008 13:46:38 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <48593586.9040600@elischer.org> <48595DB2.3030005@gritton.org> <200806182140.23123.zec@icir.org> In-Reply-To: <200806182140.23123.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 19:46:46 -0000 Marko Zec wrote: > The only thing I'd like to have > as an option is to be able to spawn a new process in the target VM > _without_ making it chrooted... If you mean creating a jail that's not chrooted, that's no problem. If you mean creating a jail that *is* chrooted, and then placing a process into that jail without chrooting it, that would be a breakage of the jail paradigm. Hopefully you mean the former? - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:50:18 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F6071065673 for ; Wed, 18 Jun 2008 19:50:18 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2F54A8FC2B for ; Wed, 18 Jun 2008 19:50:17 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3541541C7B5; Wed, 18 Jun 2008 21:32:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id J+EIOOkuhkse; Wed, 18 Jun 2008 21:32:23 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id BE1D341C7B4; Wed, 18 Jun 2008 21:32:23 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AE47D44487F; Wed, 18 Jun 2008 19:32:03 +0000 (UTC) Date: Wed, 18 Jun 2008 19:32:03 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD Current In-Reply-To: <485935FF.8040308@elischer.org> Message-ID: <20080618192903.O83875@maildrop.int.zabbadoz.net> References: <484CC690.9020303@elischer.org> <48536C9A.8020801@elischer.org> <20080618151911.GB46885@obiwan.tataz.chchile.org> <485935FF.8040308@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-virtualization@freebsd.org Subject: Re: Vimage headsup.. revised. X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 19:50:18 -0000 On Wed, 18 Jun 2008, Julian Elischer wrote: > Jeremie Le Hen wrote: >> Hi all, >> >> On Sat, Jun 14, 2008 at 12:00:42AM -0700, Julian Elischer wrote: >>> Also some interesting work has turned up that may be relevent >>> at the later stages WRT cobining vimage and jails. >> >> Is it possible to follow this work/discussion somewhere? >> >> Besides, I'd like to join the freebsd-virtualization@ mailing-list, but >> I can't see it in Mailman. Is it a private one? >> >> Thanks and regards, > > > I've asked teh admins to get the virtualization mailing list archived and > more generally available.. I has always been I think - as the "private" thing was sorted out before creation. It's on http://lists.freebsd.org/mailman/listinfo you can also go there directly: http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization http://lists.freebsd.org/pipermail/freebsd-virtualization/ !!!!!!!! be sure to read this though: http://lists.freebsd.org/pipermail/freebsd-virtualization/2008-May/000000.html !!!!!!!! It seems to be missing in the handbook still. Dunno why. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:57:01 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FE80106566C for ; Wed, 18 Jun 2008 19:57:01 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id B02BE8FC20 for ; Wed, 18 Jun 2008 19:57:00 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id CD0929B646; Wed, 18 Jun 2008 21:56:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.112] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id E6AAD9B644; Wed, 18 Jun 2008 21:56:58 +0200 (CEST) From: Marko Zec To: James Gritton Date: Wed, 18 Jun 2008 21:56:37 +0200 User-Agent: KMail/1.9.7 References: <48588595.7020709@gritton.org> <200806182140.23123.zec@icir.org> <4859661E.9070502@gritton.org> In-Reply-To: <4859661E.9070502@gritton.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806182156.37998.zec@icir.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 19:57:01 -0000 On Wednesday 18 June 2008 21:46:38 James Gritton wrote: > Marko Zec wrote: > > The only thing I'd like to have > > as an option is to be able to spawn a new process in the target VM > > _without_ making it chrooted... > > If you mean creating a jail that's not chrooted, that's no problem. > If you mean creating a jail that *is* chrooted, and then placing a > process into that jail without chrooting it, that would be a breakage > of the jail paradigm. Hopefully you mean the former? No, I want the later, as an option. Given that the parent environment / jail completely controls the child anyhow, I don't think such an (optional) behavior would be too big a security issue. Marko From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 20:08:03 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF5E0106567F for ; Wed, 18 Jun 2008 20:08:03 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9B10A8FC14 for ; Wed, 18 Jun 2008 20:08:03 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IK82a6010674; Wed, 18 Jun 2008 14:08:02 -0600 (MDT) Message-ID: <48596B1D.8000801@gritton.org> Date: Wed, 18 Jun 2008 14:07:57 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <200806182140.23123.zec@icir.org> <4859661E.9070502@gritton.org> <200806182156.37998.zec@icir.org> In-Reply-To: <200806182156.37998.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 20:08:04 -0000 Marko Zec wrote: >>> The only thing I'd like to have >>> as an option is to be able to spawn a new process in the target VM >>> _without_ making it chrooted... >> >> If you mean creating a jail that's not chrooted, that's no problem. >> If you mean creating a jail that *is* chrooted, and then placing a >> process into that jail without chrooting it, that would be a breakage >> of the jail paradigm. Hopefully you mean the former? > > No, I want the later, as an option. Given that the parent environment / > jail completely controls the child anyhow, I don't think such an > (optional) behavior would be too big a security issue. I'm thinking of the security implications, but of the mess. The existing jail_attach() wouldn't be sufficient, as it only passes a jid. You'd need a separate jail_attach2() sysctl call. Would this be exactly the same as jail_attach() except that it doesn't do the chroot? That sounds like a one-off to me. So would you instead have a way of specifying which parts of the jail environment you do and don't want? Then you'd have to not only know what virtualizations a jail does and doesn't do (the problem I'm working on), but also what virtualizations every process in a jail may or may not have enabled. It might be that only the chroot can reasonable support this kind of split anyway. Why do you want this? If you want to be part of the jail, you attach to it. If you want to do administration of the jail environment, it should be sufficient to do it from outside. - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 20:18:01 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ABBC1065678 for ; Wed, 18 Jun 2008 20:18:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 491D28FC19 for ; Wed, 18 Jun 2008 20:18:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 0EBB222EB; Wed, 18 Jun 2008 13:18:01 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 905182D6010; Wed, 18 Jun 2008 13:18:00 -0700 (PDT) Message-ID: <48596D7F.2060203@elischer.org> Date: Wed, 18 Jun 2008 13:18:07 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <484CC690.9020303@elischer.org> <48536C9A.8020801@elischer.org> <20080618151911.GB46885@obiwan.tataz.chchile.org> <485935FF.8040308@elischer.org> <20080618192903.O83875@maildrop.int.zabbadoz.net> In-Reply-To: <20080618192903.O83875@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-virtualization@freebsd.org Subject: Re: Vimage headsup.. revised. X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 20:18:01 -0000 Bjoern A. Zeeb wrote: > On Wed, 18 Jun 2008, Julian Elischer wrote: > >> Jeremie Le Hen wrote: >>> Hi all, >>> >>> On Sat, Jun 14, 2008 at 12:00:42AM -0700, Julian Elischer wrote: >>>> Also some interesting work has turned up that may be relevent >>>> at the later stages WRT cobining vimage and jails. >>> >>> Is it possible to follow this work/discussion somewhere? >>> >>> Besides, I'd like to join the freebsd-virtualization@ mailing-list, but >>> I can't see it in Mailman. Is it a private one? >>> >>> Thanks and regards, >> >> >> I've asked teh admins to get the virtualization mailing list archived >> and more generally available.. > > I has always been I think - as the "private" thing was sorted out > before creation. > > It's on > http://lists.freebsd.org/mailman/listinfo > > you can also go there directly: > > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > http://lists.freebsd.org/pipermail/freebsd-virtualization/ but you can't get to it via http://www.freebsd.org/search/search.html#mailinglists > > !!!!!!!! > be sure to read this though: > > http://lists.freebsd.org/pipermail/freebsd-virtualization/2008-May/000000.html > > !!!!!!!! > > It seems to be missing in the handbook still. Dunno why. > > /bz > From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 20:22:29 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA56106566B for ; Wed, 18 Jun 2008 20:22:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6D99F8FC0C for ; Wed, 18 Jun 2008 20:22:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 125812408; Wed, 18 Jun 2008 13:22:29 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B515D2D6006; Wed, 18 Jun 2008 13:22:28 -0700 (PDT) Message-ID: <48596E8B.6010906@elischer.org> Date: Wed, 18 Jun 2008 13:22:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Marko Zec References: <48588595.7020709@gritton.org> <48593586.9040600@elischer.org> <48595DB2.3030005@gritton.org> <200806182140.23123.zec@icir.org> In-Reply-To: <200806182140.23123.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 20:22:29 -0000 Marko Zec wrote: > On Wednesday 18 June 2008 21:10:42 James Gritton wrote: >> Julian Elischer wrote: >> >>> the man page for vimage(8) says for the chroot parameter: >> >>> >> >>> chroot >> >>> Set the chroot directory for the virtual image. All new >> >>> processes spawned into the target virtual image using the vimage >> >>> command will be initially chrooted to that directory. This >> >>> parameter can be changed only when no processes are running >> >>> within the target virtual image. Note that it is not required to >> >>> have a chrooted environment for a virtual image operate, which >> >>> is also the default behavior. >> >>> >> >>> so the croot is fixed unless there is no-one using it. >> > >> > Note that one could also read "or children images" I think in some >> > of >> >> these checks.. >> >> >> The situation with setting the chroot path becomes more complicated >> the more I look at it. If I replicate the vimage behavior of being >> able to set jails more than one level below the current jail >> (i.e. create "foo.bar.baz" which would be placed under the current >> "foo.bar"), then there's not necessarily a connection between place >> in the prison hierarchy and the file hierarchy. I could create jail >> "foo.bar" rooted at /home/foo/bar and then create "foo.bar.baz" >> rooted at /home/baz. That's kind of nonintuitive. > > True. Chrooting "foo.bar.baz" at absolute path > of /home/foo/bar/home/baz could be a more logical action. > >> Or perhaps I >> could restrict the chroot pathname lookup not to the caller's root, >> but to the parent jail's root. But pathnames that are looked up with >> something other that the root of the process doing the looking is >> also rather counterintuitive. >> >> And then there's the possibility of changing the root path. Suppose >> I have "foo" at /home/foo and "foo.bar" at home.bar. If I then >> change foo's home to /jail/foo, does foo.bar's jail likewise change >> to /home/foo/bar? What if /jail/foo/bar doesn't exist? Should the >> whole thing fail, or would I have foo now at /jail/foo and foo.bar at >> /home/foo/bar? I could just not recursively re-root child jails when >> I change a chroot path - except I still should if foo.bar isn't >> separately chrooted and also lives at /home/foo. >> >> Making things even worse, jail allows relative chroot paths. Those >> saved pathnames (used for prison_canseemount and >> prison_enforce_statfs) are totally useless when the erstwhile current >> directory is unknown. I'd just not allow them, but the current >> behavior of rendering all mount points essentially invisible under >> such circumstances seems reasonable. But there'd certainly be no way >> to relate a relative chroot pathname to its place in any parent >> jails. >> >> The upshot of all this is that for now, I'm sticking with only >> allowing the path to be set when a jail is created. >> >> The vimage implementation of all this seems to consist entirely of >> the quoted man page, so I can't just go there for answers. > > vimage(8) simply invokes chroot(2) to the target directory (stored a > plaintext string in the kernel) before spawning a new process inside > the target VM. > > Obviously such an approach has served only as a proof of concept hack > (though there's some anecdotal evidence some ISPs have been making > money using precisely such vimage implementation on FreeBSD 4.11). > Hence, don't feel constrained by the legacy of such kludges, and feel > free to propose better alternatives. The only thing I'd like to have > as an option is to be able to spawn a new process in the target VM > _without_ making it chrooted... I'd say that there is no choice.. it has to be chrooted.. to something.. but that chroot could be either the chroot of the parent or a subdirectory of that. it can not be a directory back toward the root from the parent's chroot. > > Marko From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 20:26:27 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B24106567C; Wed, 18 Jun 2008 20:26:27 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 193F68FC15; Wed, 18 Jun 2008 20:26:26 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 184523F624D; Wed, 18 Jun 2008 22:26:26 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id A8CA43F61C2; Wed, 18 Jun 2008 22:26:24 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 386E79B497; Wed, 18 Jun 2008 20:22:12 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 2C05A4089; Wed, 18 Jun 2008 22:22:12 +0200 (CEST) Date: Wed, 18 Jun 2008 22:22:12 +0200 From: Jeremie Le Hen To: "Bjoern A. Zeeb" Message-ID: <20080618202212.GF46885@obiwan.tataz.chchile.org> References: <484CC690.9020303@elischer.org> <48536C9A.8020801@elischer.org> <20080618151911.GB46885@obiwan.tataz.chchile.org> <485935FF.8040308@elischer.org> <20080618192903.O83875@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618192903.O83875@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: FreeBSD Current , freebsd-virtualization@freebsd.org Subject: Re: Vimage headsup.. revised. X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 20:26:27 -0000 On Wed, Jun 18, 2008 at 07:32:03PM +0000, Bjoern A. Zeeb wrote: > !!!!!!!! > be sure to read this though: > > http://lists.freebsd.org/pipermail/freebsd-virtualization/2008-May/000000.html > !!!!!!!! You may want to ask postmaster@ to put this message in the mailing-list description for now. (See "About freebsd-virtualization" on http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization) Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 20:59:31 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1133106566C for ; Wed, 18 Jun 2008 20:59:31 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9799A8FC15 for ; Wed, 18 Jun 2008 20:59:31 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IKxUYd012606 for ; Wed, 18 Jun 2008 14:59:31 -0600 (MDT) Message-ID: <4859772D.5030208@gritton.org> Date: Wed, 18 Jun 2008 14:59:25 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Subject: How rootvnode is used X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 20:59:32 -0000 A closer look at rootvnode shows it's not as heavily used as I thought it was. Almost everything uses the current process's own root directory (fd_rdir) and occasionally its jail directory (fd_jdir). Among the direct users of rootvnode, many explicitly want the system root directory: ZFS for kernel threads that don't yet have a root ZFS for opening device files, where comments say "root of the global zone". dounmount, if forcefully unmounting. vfs_mountroot. check_root, if chroot_allow_open_directories == 1 nfs_namei, with pubflag set. audit_canon_path, checking if the path came from the system root. vfs_mountroot is special, as after it sets rootvnode, I'd want to set prison0's vnode as well (currently strategy is to keep the rootvnode global and prison0.pr_root as "separate but equal"). The case of dounmount forcefully unmounting the root filesystem is only a precursor to system shutdown. One other rootvnode user is mountcheckdirs, which will change rootvnode if it's mounted on top of. This also checks the cdir, rdir ,and fdir of every process in the system, and should be augmented to also check the pr_root of every prison (including prison0). Aside from the initial vfs_mountroot call, this is the only way rootvnode's value is ever changed. All other uses of rootvnode involve walking up the file tree: lookup will stop at fd_rdir or fd_jdir or fd_rootvnode when looking up "..". It should also stop at the current prison's pr_root. vn_fullpath1 (kern___getcwd and vn_fullpath) stop at fd_rdir or fd_rootvnode. In addition to stopping at the current prison's pr_root, it should check fd_jdir as well. linux_getcwd only uses rootvnode when fd_rdir is null (which as far as I can tell never happens in user threads, and kernel threads don't go here). Thus it really only stops at fd_rdir. It returns an error if it gets to real root before the process root (i.e. if an open directory was fchdir'd to), so there's no particular need for checking prison root to just end up giving the same error. That leaves only four places in the kernel where prison root directories would be checked (in addition to jail_attach of course). I should be able to handle that, even with decent locking. - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 21:02:42 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2754A106568E for ; Wed, 18 Jun 2008 21:02:42 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1838FC1D for ; Wed, 18 Jun 2008 21:02:41 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IL2eOr012751; Wed, 18 Jun 2008 15:02:40 -0600 (MDT) Message-ID: <485977EB.90504@gritton.org> Date: Wed, 18 Jun 2008 15:02:35 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <200806182140.23123.zec@icir.org> <4859661E.9070502@gritton.org> <200806182156.37998.zec@icir.org> In-Reply-To: <200806182156.37998.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 21:02:42 -0000 Marko Zec wrote: >>> The only thing I'd like to have >>> as an option is to be able to spawn a new process in the target VM >>> _without_ making it chrooted... >> >> If you mean creating a jail that's not chrooted, that's no problem. >> If you mean creating a jail that *is* chrooted, and then placing a >> process into that jail without chrooting it, that would be a breakage >> of the jail paradigm. Hopefully you mean the former? > > No, I want the later, as an option. Given that the parent environment / > jail completely controls the child anyhow, I don't think such an > (optional) behavior would be too big a security issue. One thing you could do is keep a file descriptor open to the real root directory, and call jail_attach(). As long as the system is in its default state of chroot_allow_open_directories == 1, you can then fchdir() or openat() from the saved descriptor. That could easily be made an option to jexec(8). - Jamie From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 21:04:21 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13CF8106566C for ; Wed, 18 Jun 2008 21:04:21 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9156E8FC18 for ; Wed, 18 Jun 2008 21:04:20 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 4536E9B64E; Wed, 18 Jun 2008 23:04:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.112] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 16C499B649; Wed, 18 Jun 2008 23:04:17 +0200 (CEST) From: Marko Zec To: James Gritton Date: Wed, 18 Jun 2008 23:03:56 +0200 User-Agent: KMail/1.9.7 References: <48588595.7020709@gritton.org> <200806182156.37998.zec@icir.org> <48596B1D.8000801@gritton.org> In-Reply-To: <48596B1D.8000801@gritton.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806182303.57184.zec@icir.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 21:04:21 -0000 On Wednesday 18 June 2008 22:07:57 James Gritton wrote: > Marko Zec wrote: > >>> The only thing I'd like to have > >>> as an option is to be able to spawn a new process in the target > >>> VM _without_ making it chrooted... > >> > >> If you mean creating a jail that's not chrooted, that's no > >> problem. If you mean creating a jail that *is* chrooted, and then > >> placing a process into that jail without chrooting it, that would > >> be a breakage of the jail paradigm. Hopefully you mean the > >> former? > > > > No, I want the later, as an option. Given that the parent > > environment / jail completely controls the child anyhow, I don't > > think such an (optional) behavior would be too big a security > > issue. > > I'm thinking of the security implications, but of the mess. The > existing jail_attach() wouldn't be sufficient, as it only passes a > jid. You'd need a separate jail_attach2() sysctl call. Would this > be exactly the same as jail_attach() except that it doesn't do the > chroot? That sounds like a one-off to me. So would you instead have > a way of specifying which parts of the jail environment you do and > don't want? Then you'd have to not only know what virtualizations a > jail does and doesn't do (the problem I'm working on), but also what > virtualizations every process in a jail may or may not have enabled. > It might be that only the chroot can reasonable support this kind of > split anyway. > > Why do you want this? If you want to be part of the jail, you attach > to it. If you want to do administration of the jail environment, it > should be sufficient to do it from outside. Consider a situation where the directory tree of a jail would get corrupted or compromised (by accident or maliciously), so that you couldn't or wouldn't wish to exec any binaries from that part of the filesystem tree, but you'd like to check the network state / setup there (TCP connections, routes, firewall...), perhaps do a tcpdump capture and store it in a file inaccessible to processes already running in that jail... Marko From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 19 19:04:10 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 292321065670 for ; Thu, 19 Jun 2008 19:04:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 05E368FC0C for ; Thu, 19 Jun 2008 19:04:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id CF6512365; Thu, 19 Jun 2008 12:04:10 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id AD6F12D6022; Thu, 19 Jun 2008 12:04:09 -0700 (PDT) Message-ID: <485AADB0.8080006@elischer.org> Date: Thu, 19 Jun 2008 12:04:16 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org, Marko Zec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: vimage (and vimage-devel) branches X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2008 19:04:10 -0000 Status: Currently they are compiling GENERIC fine, and VIMAGE ok, but failing to compile LINT the current points I know we need to work on are: sctp: I'm working with randall on this pf: we need a pf maintainer to take a look and decide the right things to do for this. the work that is being don on the vimage/jail merge (something I didn't expect to happen so quickly) needs to be looked at to see how it affects our schedule. The vimage-commit2 branch is looking fine but I want to do some additions for SCTP in it. From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 19 19:49:07 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E75601065682 for ; Thu, 19 Jun 2008 19:49:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id C1C488FC13 for ; Thu, 19 Jun 2008 19:49:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 78EFE2426; Thu, 19 Jun 2008 12:49:08 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 540BB2D6017; Thu, 19 Jun 2008 12:49:07 -0700 (PDT) Message-ID: <485AB83A.5020006@elischer.org> Date: Thu, 19 Jun 2008 12:49:14 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Marko Zec References: <485AADB0.8080006@elischer.org> <200806192147.22285.zec@freebsd.org> In-Reply-To: <200806192147.22285.zec@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: vimage (and vimage-devel) branches X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2008 19:49:08 -0000 Marko Zec wrote: > On Thursday 19 June 2008 21:04:16 Julian Elischer wrote: >> Status: >> >> Currently they are compiling GENERIC fine, and VIMAGE >> ok, but failing to compile LINT > > LINT compiles fine on i386 / vimage-commit2, but not on other branches. yes > > Marko > >> the current points I know we need to work on are: >> >> sctp: I'm working with randall on this >> pf: we need a pf maintainer to take a look and decide >> the right things to do for this. >> >> the work that is being don on the vimage/jail >> merge (something I didn't expect to happen so quickly) >> needs to be looked at to see how it affects our schedule. >> >> >> The vimage-commit2 branch is looking fine >> but I want to do some additions for SCTP in it. > From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 19 19:47:45 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA801065691 for ; Thu, 19 Jun 2008 19:47:45 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 98CB68FC0A for ; Thu, 19 Jun 2008 19:47:45 +0000 (UTC) (envelope-from zec@freebsd.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id F0FB79B648; Thu, 19 Jun 2008 21:47:44 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.112] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 142959B644; Thu, 19 Jun 2008 21:47:44 +0200 (CEST) From: Marko Zec To: Julian Elischer Date: Thu, 19 Jun 2008 21:47:22 +0200 User-Agent: KMail/1.9.7 References: <485AADB0.8080006@elischer.org> In-Reply-To: <485AADB0.8080006@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806192147.22285.zec@freebsd.org> X-Mailman-Approved-At: Thu, 19 Jun 2008 20:06:14 +0000 Cc: freebsd-virtualization@freebsd.org Subject: Re: vimage (and vimage-devel) branches X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2008 19:47:46 -0000 On Thursday 19 June 2008 21:04:16 Julian Elischer wrote: > Status: > > Currently they are compiling GENERIC fine, and VIMAGE > ok, but failing to compile LINT LINT compiles fine on i386 / vimage-commit2, but not on other branches. Marko > the current points I know we need to work on are: > > sctp: I'm working with randall on this > pf: we need a pf maintainer to take a look and decide > the right things to do for this. > > the work that is being don on the vimage/jail > merge (something I didn't expect to happen so quickly) > needs to be looked at to see how it affects our schedule. > > > The vimage-commit2 branch is looking fine > but I want to do some additions for SCTP in it.