Date: Wed, 24 Oct 2007 10:49:00 -0700 From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@icir.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 127942 for review Message-ID: <471F858C.20802@elischer.org> In-Reply-To: <200710240139.00008.zec@icir.org> References: <200710230018.l9N0IO8l020652@repoman.freebsd.org> <200710232314.38149.zec@icir.org> <471E7645.1030503@elischer.org> <200710240139.00008.zec@icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Marko Zec wrote: > On Wednesday 24 October 2007 00:31:33 Julian Elischer wrote: >> Marko Zec wrote: >>> On Tuesday 23 October 2007 02:49:24 Julian Elischer wrote: >>>> question: >>>> >>>> can processes in two vimages communicate if they both have access >>>> to the same named pipe/fifo in the filesystem? >>> Yes, provided that they open the fifo while they would be both >>> attached to the same vnet. Once the sockets would become open the >>> processes could reassociate to arbitrary vimages, while the sockets >>> would remain bound to their original vnets for their entire >>> lifetime duration. >> hmm that's not what I want... what I want is an ability for processes >> in two overlapping vimages to communicate easily without incuring the >> overhead of going throigh a virtual router. >> >> another possibility is a >> local: interface (address 127.1.[vnet number]) which acts like a >> local net between the virtual machines. > > Uhh I'd rather not take that path... This would require at least a) > lots of special casing all around IP stack; and b) that vimages/vnets > would need to be directly addressable by small integers. > > I'd prefer if we could work out a solution where symbolic (textual) > naming of vimages/vnets would be sufficient for all purposes... > >>> As an alternative, we could / should introduce an extended socket() >>> syscall where an additional argument would explicitly specify to >>> which vimage/vnet the new socket should belong. >> if a process in the root vimage makes fifo in >> /vimages/vimage1/usr/tmp/fifo1 >> >> and a process in vimage1 (that is chrooted at /vimages/vimage1/) >> opens the fifo at /usr/tmp/fifo1 >> >> why can't they communicate? I'm surprised at this.. > > You're right the example you gave above actually works I just tried this > out (now I'm slightly surprised :). However netstat -f unix will show > the socket pair only in one of the vimages/vnets... I don't know why I > thought there was also a prison_check() call somewhere inside or around > unp_connect() but apparently there isn't... > > So while this obviously works for you I'm not entirely sure that this is > the behavior we wish to have... As a named pipe is a note in the filesystem that both can see it would be extremely POLA if they didn't refer to the same object.. If you do make this happen, please make it configurable. > Cheers, > > Marko >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?471F858C.20802>