On Thu, Oct 2, 2008 at 2:23 PM, Nicolas Dorfsman <[EMAIL PROTECTED]> wrote:
> Sure.
> But I think it's a bad idea.
> We must not create a hole where the operating system is secured.
> Even if you think it doesn't mind because you know the existence of
> this file(hole), what could be the consequence in the next
> future...the guy who is using this container may not know...even the
> guy who will get your job in the far future.

The overall availability of a server comes from a number of factors
which include security and usability.  If the level of separation that
you are worried about is a critical factor, I'd suggest not using
zones.  They are good but they can leak information about each other.

If an organization does not have a good process for documenting the
relationship between real and virtual machines[1], the availability of
the services running in a zone can be dramatically enhanced by
allowing those that care and feed for software within a zone to know
the name of the global zone.  They can then use this information when
they contact the helpdesk/sysadmin team/whatever to ask for help on
their broken virtualized OS instance.

Another case is if an application has application-level clustering to
provide HA.  It doesn't take too paranoid of an application
administrator to say that it is a good idea to be sure that the
various redundant virtual OS instances are not all on a single
physical machine.

Zones are wonderful, but to date I haven't seen a widely available
tool that makes this type of information and management easy to do
without implementing some large and/or costly virtualization
management framework.

FWIW, there are ways[2] that the global zone's identity leaks into
non-global zones but not in a reliable enough way to answer the
question in a generic sense.

To answer  the OP, a common way to do this is with something like:

zonecfg -z myzone
add fs
set type=lofs
set options=ro
set special=/etc/nodename
set dir=/etc/globalname

Next time the zone boots, /etc/globalname will be a file that has the
same contents as the global zone's /etc/nodename.  It is not
modifiable in the non-global zone.

1. Let's pretend that a zone is a virtual machine.  I could make the
same argument using longer sentences if that makes someone happy.
2. For example, if you know all global zones are on the
subnet, the following will give you a pretty good clue.  Other zones
on the same machine will be false positives - but naming standards and
dedicated subnets will often times help you find what you are looking

#! /bin/bash
for ip in 192.168.2.{1..255} ; do
     route get $ip | grep 8232 >/dev/null && echo Global zone: $ip

Mike Gerdts
zones-discuss mailing list

Reply via email to