[ovs-dev] [ovs-discuss] Somebody making --user and dpdk compatible again?

Ansis Atteka ansisatteka at gmail.com
Wed Jan 27 08:29:59 UTC 2016


On 26 January 2016 at 11:07, Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

> Hi Ansis,
> the links I referred were older and yes some had apparmor/selinux issues.
> I didn't refer so much to the issues they had, but more to the fact that
> they usually ended up running vswitchd as different user.
> But most of that is fixed in the respective distributions already.
> I did a quick test a few days ago disabling all of the which didn't change
> the situation, so I reenabled them again.
>
> I already checked the processes and sockets with ps/ls and such.
> Vswitchd ran as root - so was the ownership of the sockets (root:root with
> srwxr-xr-x).
> kvm/libvirt/qemu in my case is running as user libvirt-qemu and that
> mismatch to the socket is what caused the permission denied, just basic
> file permissions/ownership.
>
> This is what got me to --user, which was working nice in general but as
> mentioned is mutually exclusive to dpdk as of now.
>
> I found the following to be a simplification of the Test with kvm:
>   socat - UNIX-CONNECT:/var/run/openvswitch/vhost-user-1
> You can run that from various users as you need.
>
> I'm happy if we at some point want to do more fine grained apparmor/selinux
> profiles to confine things more.
> But IMHO they won't overcome the basic access issue as long as qemu just
> isn't allowed to access the unix socket.
>

Hi Christian.

Yes, MAC (SELinux and Apparmor) can't magically allow actions that are
blocked by DAC (Linux user:group) or vice versa. Both of them are two
independent access control solutions.

Here are the 4 possible solutions that I see:

1. OVS downgrades from "root" to "openvswitch"; The user under which KVM
runs gets added to "openvswitch" group.
2. OVS runs as root, but allows to set through OVSDB "kvm" or any other
user as owner for UNIX domain socket; After that KVM process simply
connects to that socket.
3. OVS runs as root; KVM process starts as root, opens the socket to
OVS and then downgrades to "kvm" user.
4. OVS runs as root; KVM runs as root; Both processes are confined through
Mandatory Access Control instead.

Basically solution #1 is what --user flag was intended to do. Though, you
would have to run Open vSwitch under "openvswitch" user and not "kvm".
Also, Open vSwitch may need to be restarted on certain configuration
changes that need OVS to have access again to only-root resources.

However, based on the chown/chmod commands that you invoked you are
expecting something like #2. You still need "root" access at least for
short time because the right socket owner needs to be specified for
that UNIX domain socket (either through OVSDB socket or other means).

I believe solution #3 would work if KVM's --runas flag would
make KVM process to downgrade user only after it opened that socket. I
suppose this did not work for you? This would also not survive "only OVS
reboot". Note that solution #1 and #3 are like-symmetric opposites.

Solution #4 is what I think is the right solution. However, even this may
not be silver bullet for all the situations (see the other email). What I
like about it is that discretionary access control policy does not pollute
domain logic.

Let me know which you think would be the right solution?

Best regards,
Ansis


> The sockets themselves are created from dpdk code
> (rte_vhost_driver_register).
> Unfortunately that DPDK interface has no API piece regarding socket
> ownership.
> But eventually OVS is "owning" the socket.
> We are passing that path to DPDK, we own it afterwards (since it is
> user:group of the runnign process) and we could change the ownership.
> I'm currently experimenting with a patch adding an OVS parameter to allow
> the specification of the user:group of the created vhost_user sockets.
> That would allow to "let" ovs-dpdk run as root:root in general but permit
> access to these sockets to other users/groups as the admin specifies.
>
> Here a little example messin' around with a running ovs-dpdk that just
> created the socket:
> srwxr-xr-x  1 root root    0 Jan 26 10:47 vhost-user-1=
> $ sudo -u libvirt-qemu socat -
> UNIX-CONNECT:/var/run/openvswitch/vhost-user-1
> 2016/01/26 19:00:19 socat[5006] E connect(5, AF=1
> "/var/run/openvswitch/vhost-user-1", 35): Permission denied
> $ sudo chown root:kvm /var/run/openvswitch/vhost-user-1
> $ sudo chmod g+w /var/run/openvswitch/vhost-user-1
> srwxrwxr-x  1 root kvm     0 Jan 26 10:47 vhost-user-1=
> $ sudo -u libvirt-qemu socat -
> UNIX-CONNECT:/var/run/openvswitch/vhost-user-1
> *working*
>
>
>
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>
> On Tue, Jan 26, 2016 at 7:33 PM, Ansis Atteka <aatteka at vmware.com> wrote:
>
> > Hi,
> >
> >
> > In fact I think we should remove any Discretionary Access Control
> > (--user) and ​implement proper Mandatory Access Control (SELinux and
> > Apparmor) support. Unless anyone can bring up a good case to keep and/or
> > extend DAC feature in OVS.
> >
> >
> > The link you posted seems to mention Apparmor as the root cause for
> > Permission Denied issue and not File Access bits - however this
> contradicts
> > wit the fact that chown helped you to get rid of the error.
> >
> >
> > To verify this can you do:
> >
> > 1. ps -Af for both processes that create and connect to the sokcet.
> >
> > 2. ls -la for the socket that is getting permission denied?
> >
> >
> > Thanks,
> >
> > Ansis
> > ------------------------------
> > *From:* discuss <discuss-bounces at openvswitch.org> on behalf of Christian
> > Ehrhardt <christian.ehrhardt at canonical.com>
> > *Sent:* Monday, January 25, 2016 10:32 PM
> > *To:* dev at openvswitch.org; discuss at openvswitch.org
> > *Subject:* [ovs-discuss] Somebody making --user and dpdk compatible
> again?
> >
> > Hi,
> > to avoid missing another work already been done (and google didn't find
> me
> > anything).
> > Is there already work going on to get --user and dpdk working together?
> > (see http://openvswitch.org/pipermail/dev/2015-September/060382.html)
> >
> > Background:
> > While setting up a vhost_user based ovs-dpdk setup I'm struggling to get
> > access to the vhost user sockets from qemu/kvm  due to permission issues.
> > Various mailing list posts like (
> > http://openvswitch.org/pipermail/discuss/2015-August/018553.html)
> > indicate to change the user running OVS, since the sockets are defaulting
> > to process user/group.
> > To run OVS as different user --user seems to be the preferred way.
> > But as linked above, --user has other issues with DPDK and therefore is
> > mutually exclusive for now.
> >
> > I was able to fix the permission issue with some chown/chmod, but I
> wonder
> > if there would be cleaner way to do so at some point. Maybe eventually
> the
> > approach is totally different anyway (like only specifying :group for the
> > sockets to be created). But I wondered if that old mail thread is still
> > worked on by somebody atm.
> >
> > Christian Ehrhardt
> > Software Engineer, Ubuntu Server
> > Canonical Ltd
> >
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>



More information about the dev mailing list