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
end
verify
commit
exit
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 192.168.1.0/24
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
for.
#! /bin/bash
for ip in 192.168.2.{1..255} ; do
route get $ip | grep 8232 >/dev/null && echo Global zone: $ip
done
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
