Gary Winiger wrote: >>> 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..
Gary, your understanding is correct. 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
