PERFORCE change 127942 for review

[Marko Zec]

On Wednesday 24 October 2007 19:49:00 Julian Elischer wrote:
> 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.

OK I won't change the current behavior of named pipes accross boundary 
of two vnets, unless somebody steps up with a different view / 
argumentation...

Marko