Date: Wed, 18 Jun 2008 09:56:38 -0600 From: James Gritton <jamie@gritton.org> To: freebsd-virtualization@freebsd.org Cc: Julian Elischer <julian@elischer.org> Subject: Re: V_* meta-symbols and locking Message-ID: <48593036.60502@gritton.org> In-Reply-To: <4858ADCC.1050909@elischer.org> References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48593036.60502>