> > 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..
>
> Gary, your understanding is correct.
This and
> Please note that this case doesn't allow communication between
> two non-global zones.
the final statement don't seem to match what I'm asking.
Let me try again. Simply why, if the rendezvous is visable,
i.e., can be opened/is visible in ANY zone, can't the peer
communicate with the creator of the rendezvous?
Networking folk, please excuse me if I don't have the terminology
right.
I'm not talking about how a labeled system differs from an
unlabeled system. I'm asking about all configurations of
OpenSolaris and S10.
If an admin creates a way that zones can share a rendezvous
file, why should there be any further restriction?
Project team, have the zones and networking teams been asked
about this? I don't recall seeing an explicit response.
Perhaps, a final spec is needed after the case converges
to make this part of the case clear.
Gary..
======
> For two processes to communicate using unix domain sockets, they
> need to be using the same rendezvous. Under the current proposal,
> the server that creates the socket resides in the global zone.
> A non-global zone client can communicate with this server using
> the unix domain socket only if it uses the same rendezvous.
>
> What Ric was saying was that rendezvous need to be loop-back mounted
> in the non-global zone from the global zone. How it gets mounted will
> depend on the subsystem that uses this feature. This mounting obviously
> will have to be done either by an admin (manually) or automatically
> (by smf or some other means).
>
> I don't think Ric is adding any new code to check if the rendezvous
> is loop-back mounted (because the check is already there i.e
> the communicating processes have to use the *same* rendezvous).
>
> For example, in case of Trusted Extensions X, the X server creates
> the rendezvous in a location that is loopback mounted via an smf
> service. The X clients use this new rendezvous to communicate with
> the X server.
>
> Please note that this case doesn't allow communication between
> two non-global zones.
>
> -Lokanath
>
