Re: [RFC] eal: provide option to set vhost_user socket owner/permissions

[Yuanhan Liu <yuanhan.liu@linux.intel.com>]

On Wed, Feb 15, 2017 at 09:32:27AM -0500, Aaron Conole wrote:
> Thomas Monjalon <thomas.monjalon@6wind.com> writes:
> 
> > Was there any progress on this topic?
> > Can we close the request?
> > 	http://dpdk.org/patch/12222/
> 
> No update in almost a year is probably a bad sign.
> 
> >From the OVS side, we've dropped our patches due to too many corner
> cases handling this - instead we're opting to use vhost-user client
> mode, and punt the issue to the 'other' side.  Additionally, I do agree
> with the criticism that providing this via an EAL command line option is
> wrong. So, I think it can be safely dropped.

Yes and I think we already came an agreement on that before. The reason
I still kept in patchwork is to let it be a (soft) reminder: it's
something might could be enhanced.

> That said, if this is something that folks really want to solve, I think
> the sanest way is to allow the application to pass in a
> file-descriptor.  The way unix domain sockets permissions work changes
> based on far too many factors to ever provide an API that makes sense,
> unless we also bake in tests for various OSes (and possibly even flavors
> of OSes).
> 
> Instead, I think DPDK should allow the application to open the unix
> domain socket in whatever manner it chooses, doing whatever tricks are
> required to set permissions or other flags the way it wants, and then
> pass the file descriptor into the framework.  This would allow doing
> sane things like fork()ing, changing current owner and umask, opening
> the socket, and passing the descriptor back through a pipe (which works
> on FreeBSD and Linux to set the permissions).  It allows the application
> to be concerned with the file-system details, and lets DPDK merely worry
> about the important thing: passing packet data.

I think I could consider that if that's really needed, say, a real need
from some customers.

My last reply to that is, you could use the vhost-user as client mode,
whereas the socket file is managed/created by QEMU, thus permission
won't be an issue any more.

Another thing worth noting is that, IIUC, OVS guys at Ireland were proposing
to drop the vhost-user support and replace it with vhost-pmd, whereas you
could specific vdev options to specify the socket permissions (and etc) for
the server mode. It won't use EAL command line options any more, thus,
no block issue.

	--yliu
> 
> > 2016-04-27 16:08, Yuanhan Liu:
> >> On Tue, Apr 26, 2016 at 09:33:48AM -0400, Aaron Conole wrote:
> >> > >> > b) would prefer a change of the API?
> >> > >> 
> >> > >> Adding a new option to the current register API might will not work well,
> >> > >> either. It gives you no ability to do a dynamic change later. I mean,
> >> > >> taking OVS as an example, OVS provides you the flexible ability to do all
> >> > >> kinds of configuration in a dynamic way, say number of rx queues. If we
> >> > >> do the permissions setup in the register time, there would be no way to
> >> > >> change it later, right?
> >> > >> 
> >> > >> So, I'm thinking that we may could add a new API for that? It then would
> >> > >> allow applications to change it at anytime.
> >> > >
> >> > > A vhost API in the library?
> >> 
> >> Yes, I supposed so.
> >> 
> >> > > And for vhost PMD?
> >> 
> >> Technically, vhost PMD is an application (or precisely, an user) of
> >> vhost lib. So, it's supposed to invoke the new API.
> >> 
> >> > What about devargs parameters?
> >> 
> >> Yes, and it then invoke the API, as stated above.
> >> 
> >> > 
> >> > I don't know the most sane solution here, other than to echo the
> >> > sentiment that a new API for this is probably appropriate. Where that
> >> > API lives, and how it looks should be hashed out. For now, I'm working
> >> > on a solution in OVS because no such API or facility exists in DPDK.
> >> > 
> >> > Actually, there are a number of edge cases with vhost-user sockets. I
> >> > don't want to get into all of them, but since we're discussing the API a
> >> > bit here, I'd like to also bring up the following:
> >> > 
> >> >   What is the desired behavior w.r.t. file cleanup when the application
> >> >   crashes, restarts, and tells DPDK to use that file again (which hasn't
> >> >   been cleaned up due to the crash)?
> >> >   At present, the vhost-user code errors out. But how does the
> >> >   application correct the situation without deleting arbitrary files on
> >> >   the filesystem?
> >> 
> >> Oops, yes, that's another one. We also had some discussion before:
> >> 
> >>     http://dpdk.org/ml/archives/dev/2015-December/030326.html
> >> 
> >> It ended up with an agreement that we should let the application to
> >> handle it, due to it's a path provided by the application, though
> >> it's DPDK does the creation.
> >> 
> >> > 
> >> > >> > c) consider it an issue of consuming projects and let them take care?
> >> > >> 
> >> > >> It's not exactly an issue of consuming projects; we created the socket
> >> > >> file after all.
> >> > >
> >> > > Yes
> >> > 
> >> > Just want to reiterate at present there is no solution, so projects will
> >> > invent their own. I can point to Ubuntu and Red Hat customer bugs which
> >> > require silly workarounds like "after you started a bunch of stuff, go
> >> > to the directory and run chmod/chown."
> >> > 
> >> > I'm actually not opposed to any solution that seems sane. If DPDK takes
> >> > the stance that the file is specified by the application, and therefore
> >> > "file management" activities (removal, permissions, ownership, etc.) are
> >> > the responsibility of the application, so be it.
> >> 
> >> Exactly. But DPDK, as a library, could provides some handy APIs to make
> >> the application developer's life be less painful. So, that also echoes
> >> to what we have said before: we provide the tool, you use it, and it's
> >> you to make sure it's right.
> >> 
> >> 	--yliu
> >> 
> >> > If the stance is that
> >> > DPDK owns the management of the file, so be that as well. I think the
> >> > first case is easier for the library maintainers (do nothing), the
> >> > second is easier for the applications (use these semantics).
> >> > 
> >> > If it really is the responsibility of DPDK, then I think the only sane
> >> > approach is an API for managing this. That may require an additional
> >> > library framework to link the vhost-user PMD and rte_ethdev facilities
> >> > so that a common API could be provided.
> >> > 
> >> > Just my $.02.
> >> > 
> >> > Thanks,
> >> > Aaron