The top hit I got when I googled for lofiadm zones
was http://docs.lucidinteractive.ca/index.php/Using_lofiadm_within_a_Solaris_zone which looks like it describes a way to make that work. _However_, I would be _very_ reluctant to use it, because I strongly suspect it could open up all sorts of security holes. To make it work safely, if that's even possible, would probably require the lofi driver and perhaps additional kernel code to be zone aware, so that each zone had its own lofi devices (visible only to itself, or to root in the global zone only if they cd'd to the zones dev directory), and so that any lofi device in a non-global zone would be forced to be read-only, and any mount of such would have nodev and nosuid options forced. I don't think even that would be enough, since I very much doubt that all filesystems that might reside on a lofi device are proof against kernel crash even if the filesystem is corrupt (which cannot be prevented with a lofi device since the underlying file cannot be guaranteed to be an unmodified filesystem image as produced by trusted code). So, except perhaps under very exceptional circumstances, I'd personally regard (a) the risk as being unacceptable, and (b) work to reduce the risk to be incapable of sufficient success as to be worth undertaking. With xen guests (or LDOMs on SPARC), i.e. "true" virtual machines each with their own OS, I'd say if the guest wants to trash themselves, ok, because in principle they couldn't hurt the host. But zones aren't separate virtual machines, they're just isolated subsets of the host that provide a partial illusion of being separate VMs; this sort of situation goes beyond what that illusion is presently (and perhaps ever) capable of providing without putting the global zone (and all other non-global zones!) at risk. IMO of course, not having immersed myself in the zone-related code, nor even thought about it for more than a couple of minutes... -- This message posted from opensolaris.org
