> > Since other forms of IPC export from the global zone exists
> > (viz. doors), what's the compelling reason to not allow
> > IPC of Unix domain? That is why should this only be
> > allowed for labeled systems?
> > It seems to me there is little policy difference between
> > a door rendezvous and a Unix domain socket rendezvous
> > being exported from the GZ to another zone.
> > Has anyone checked with the Zones and networking project
> > teams?
> > IMO, the restriction should just be removed (the less TX specific
> > code the better ;-).
> >
> > Gary..
> >
>
> I'm checking with the Zones group, but from my perspective I have no
> problem with making just
> the kernel socket change "global" and not dependent on TX. So the "a)"
> part would just read:
>
> The kernel will permit labeled zones to connect to global zone
> clients if the global zone UNIX domain
> rendezvous file is made available to the zone via a loopback mount.
>
> If anyone has any issue with this plan or believes more time is needed
> to run the case due to this
> modification, please reply. As mentioned, I'll check explicitly with
> zones-core.
Maybe I don't understand this reply. Let me try again. I don't
see why there should be any check for Unix domain rendezvous.
I don't see where rendezvous even between non-global zones
is fundimentally different than IP network end points.
In particular, if something in the GZ wanted to make itself
available in local zones, it would be up to the GZ admin
to correctly set up the visibility of the rendezvous files,
just as is true for door rendezvous. Similarly for non-global
zones to see into each other's file spaces that would have to
be set up by the GZ admin. So, I'm missing why any checks
are needed.
What don't I understand about the zones policy and this proposal?
Gary..
