Gary Winiger wrote: >>> 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? >
To me it seems similar to lofs policy that TX has. That could also have been left unobstructed and at the discretion of which mounts the admins choose. Since we have policy there, it seems consistent for sockets to also have policy. > Project team, have the zones and networking teams been asked > about this? I don't recall seeing an explicit response. > I haven't had any repsonses to my queries... > Perhaps, a final spec is needed after the case converges > to make this part of the case clear. > I agree. Despite the date, this is de facto pending due to Alan's vacation. I think we should assume the case is still running until this part is resolved, which will likely run into next week when Alan and Glenn return. I believe we've narrowed it down to a just a question of TX behavior - whether any policy enforcement is needed there. The direction for non-TX is to remove cross-zone limitations. -Ric > 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 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080815/6b66e595/attachment.html>
