On Fri, Jun 24, 2016 at 07:43:29AM +0000, Loftus, Ciara wrote:
> >
> > On Tue, Jun 21, 2016 at 09:15:03AM -0400, Aaron Conole wrote:
> > > Yuanhan Liu <yuanhan.liu at linux.intel.com> writes:
> > >
> > > > On Fri, Jun 17, 2016 at 11:32:36AM -0400, Aaron Conole wrote:
> > > >> Prior to this commit, the only way to add a vhost-user socket to the
> > > >> system is by relying on librte_vhost to open the unix domain socket and
> > > >> add it to the unix socket list. This is problematic for applications
> > > >> which would like to set the permissions,
> > > >
> > > > So, you want to address the issue raised by following patch?
> > > >
> > > > http://dpdk.org/dev/patchwork/patch/12222/
> > >
> > > That patch does try to address the issue, however - it has some
> > > problems. The biggest is a TOCTTOU issue when using chown. The way to
> > > solve that issue properly is different depending on which operating
> > > system is being used (for instance, FreeBSD doesn't honor
> > > fchown(),fchmod() on file descriptors). My solution is basically to
> > > punt that responsibility to the controlling application.
> > >
> > > > I would still like to stick to my proposal, that is to introduce a
> > > > new API to do the permission change at anytime, if we end up with
> > > > wanting to introduce a new API.
> > >
> > > I've spent a lot of time looking at the TOCTTOU problem, and I think
> > > that is a really hard problem to solve portably. Might be good to just
> > > start with the flexible mechanism here that lets the application
> > > developer satisfy their own needs.
> > >
> > > >> or applications which are not
> > > >> directly allowed to open sockets due to policy restrictions.
> > > >
> > > > Could you name a specific example?
> > >
> > > SELinux policy might require one application to open the socket, and
> > > pass it back via a dbus mechanism. I can't actually think of a concrete
> > > implemented case, so it may not be valid.
> > >
> > > > BTW, JFYI, since 16.07, DPDK supports client mode. It's QEMU (acting
> > > > as the server) will create the socket file. I guess that would diminish
> > > > (or even avoid?) the permission pain that DPDK acting as server brings.
> > > > I doubt the API to do the permission change is really needed then.
> > >
> > > I wouldn't say it 'solves' the issue so much as hopes no one uses server
> > > mode in DPDK. I agree, for OvS, it could.
> >
> > Actually, I think I would (personally) suggest people to switch to DPDK
> > vhost-user client mode, for two good reasons:
> >
> > - it should solve the socket permission issue raised by you and Christian.
> >
> > - it has the "reconnect" feature since 16.07. Which means guest network
> > will still work from a DPDK vhost-user restart/crash. DPDK vhost-user
> > as server simply doesn't support that.
> >
> > And FYI, Loftus is doing the DPDK for OVS intergration. Not quite sure
> > whether she put the client mode as the default mode though.
>
> Hi Yuanhan,
Hi Ciara,
Thanks for the note.
> I intend to keep the DPDK server-mode as the default. My reasoning is that not
> all users will have access to QEMU v2.7.0 initially. We will keep operating
> as before
> but have an option to switch to DPDK client mode,
And yes, good point.
> and then perhaps look at
> switching the default in a later release.
Also okay to me.
--yliu
