Erik Nordmark writes:
> James Carlson wrote:
> 
> > I don't think that argument works on two counts.  First, exclusive-IP
> > behavior does not offer complete IP isolation, because you can't (for
> > instance) install your own copy of Firewall-1 or Cisco VPN into a
> > non-global exclusive-IP zone. 
> 
> Agreed you can't do that. But how does that make IP packets leak between 
> different exclusive-IP zones?

It doesn't make the packets leak.  It makes the administrative
activities leak.

> Perhaps we have a different definition of what "IP isolation" means?
> To me the critical property is that there is no IP packet leakage.

I don't think it's the only property.

> > Some things do still require global
> > zone administration.  Second, "ps" shows processes that the user in
> > the global zone cannot 'administer' by way of kill(2), so they are at
> > least as isolated as IP instances, but they're still of interest to
> > global zone administrators who want a global view of the system.
> 
> I tried the kill and AFAICT root in the global zone can kill a process 
> in a non-global zone:

OK.  I must be misremembering this.  I thought the restriction was
more complex than that.

> > All that said, I think making ifconfig list the interfaces present in
> > exclusive-IP zones, given the design of ifconfig, would be
> > prohibitively difficult.  It'd have no access to the DLPI nodes, which
> > is where it gets some of its information, and the ioctls it uses for
> > tunnels and the like won't work well if the zones have independent
> > control of the interfaces.  (It'd work "for now," but I think it'd end
> > up representing more confusion with Clearview, as there'd be no easy
> > way to coordinate interface names across multiple zones, so
> > ifta_lifr_name would be ambiguous.)
> 
> I agree it would be a pain to implement. zone_enter() would be one way.
> 
> But the key thing to me is the consistency between where things can be 
> observed and where they can be modified.

We already have RFEs filed against other utilities because they don't
show non-global zone activity (see, for example, CR 6369726).  I think
the lines here are pretty blurry.

In some usage models, the global zone administrator "owns"
everything.  Even if he can't directly control things from the global
zone (and must log into the non-global zone to turn services on and
off), he wants to see a view of the system that includes everything.

In other usage models, the global zone administrator just provides
"infrastructure" and has no business looking at non-global zones.  And
we've had requests to lock down the global zone so it can't look where
it shouldn't.

Given that there are some networking things that must be administered
in the global zone alone even when exclusive stack instances are in
use, it doesn't seem unreasonable to me to say that the administrator
of the global zone should be able to list related information without
entering the non-global zone.

-- 
James Carlson, KISS Network                    <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to