From: Aaron Conole <aconole@redhat.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: "Loftus\, Ciara" <ciara.loftus@intel.com>,
"dev\@dpdk.org" <dev@dpdk.org>, "Xie\,
Huawei" <huawei.xie@intel.com>,
Christian Ehrhardt <christian.ehrhardt@canonical.com>
Subject: Re: [dpdk-dev] [RFC] librte_vhost: Add unix domain socket fd registration
Date: Fri, 24 Jun 2016 08:23:52 -0400 [thread overview]
Message-ID: <87lh1uai7b.fsf@trashheap.bytheb.org> (raw)
In-Reply-To: <20160624075103.GT23111@yliu-dev.sh.intel.com> (Yuanhan Liu's message of "Fri, 24 Jun 2016 15:51:03 +0800")
Yuanhan Liu <yuanhan.liu@linux.intel.com> writes:
> 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@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.
Is there still merit to this patch, given above? If so, I'd finish my
integration and testing work and submit it formally.
next prev parent reply other threads:[~2016-06-24 12:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-17 15:32 Aaron Conole
2016-06-21 7:21 ` Yuanhan Liu
2016-06-21 13:15 ` Aaron Conole
2016-06-24 2:31 ` Yuanhan Liu
2016-06-24 7:43 ` Loftus, Ciara
2016-06-24 7:51 ` Yuanhan Liu
2016-06-24 12:23 ` Aaron Conole [this message]
2016-06-27 11:53 ` Yuanhan Liu
2016-06-27 19:19 ` Aaron Conole
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lh1uai7b.fsf@trashheap.bytheb.org \
--to=aconole@redhat.com \
--cc=christian.ehrhardt@canonical.com \
--cc=ciara.loftus@intel.com \
--cc=dev@dpdk.org \
--cc=huawei.xie@intel.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).