Created attachment 1072562 [details]
strace of ovs-vsctl add-br psedlak-bridge

Created attachment 1072563 [details]
strace of ovsdb-server service

Looks like you haven't started the openvswitch service.
Could you do that before run any OVS command?
# systemctl start openvswitch

You can also enable it to start every boot.
# systemctl enable openvswitch


Thanks
fbl

Hi Pavel, 
Please provide the information request above. 
If this is a real blocker, then we need the info from you to be able to unblock you.
If we do not get the required information in the next 5 business days we will assume it is NOT blocking you. 

thanks

So I can confirm, that when running 'systemctl start openvswitch' first it works.
Though i have to add, that in case i run 'add-br/list-br' before systemct start,
i'm getting completely different behavior/output to the one descibed in my first message:
> ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory)
based on which i would guess it's not the only thing here (like that packstack/puppet would just not started the service).

I was running it now with OpenVSwitch Preview
>  2.4.0-1.el7                  @rhelosp-rhel-7-openvswitch
but then retried also with
>  2.3.2-1.git20150730.el7_1    rhelosp-7.0-puddle
too, both giving me same result (no db.sock when tried before systemctl start, no audit/denied issues at all)

# rpm -qa | grep selinux
> libselinux-2.2.2-6.el7.x86_64
> selinux-policy-targeted-3.13.1-53.el7.noarch
> libselinux-utils-2.2.2-6.el7.x86_64
> libselinux-python-2.2.2-6.el7.x86_64
> selinux-policy-3.13.1-53.el7.noarch

Though now newer guest image was used, and there are also additional rpm updates available (incl. kernel and selinux pkgs), so seems the possibility of version-combinations to try is quite big.

I'll retry tomorrow to run the whole openstack packstack installation/tests without workaround (which is injecting selinux module to allow modules_dep_t / openvswitch_t / read,getattr,open ... as obtained by audit2allow) to see if it works now.

(In reply to Pavel Sedlák from comment #11)
> So I can confirm, that when running 'systemctl start openvswitch' first it
> works.

Excellent.

> Though i have to add, that in case i run 'add-br/list-br' before systemct
> start,
> i'm getting completely different behavior/output to the one descibed in my
> first message:
> > ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory)

That is actually the correct behavior.  Without the daemon running, the db.sock shouldn't exist and the commands can't communicate.

It seems you had a partial service running.  I mean, daemons running without the kernel module, which is possible specially when using the userspace datapath, but then it suggests a problem elsewhere because by default the module is always loaded when the service starts.

> based on which i would guess it's not the only thing here (like that
> packstack/puppet would just not started the service).

Yup, sounds like the module was prevented to be loaded in the first place when the service was started and I can't tell the reason.

> I was running it now with OpenVSwitch Preview
> >  2.4.0-1.el7                  @rhelosp-rhel-7-openvswitch
> but then retried also with
> >  2.3.2-1.git20150730.el7_1    rhelosp-7.0-puddle
> too, both giving me same result (no db.sock when tried before systemctl
> start, no audit/denied issues at all)

Ok.

> Though now newer guest image was used, and there are also additional rpm
> updates available (incl. kernel and selinux pkgs), so seems the possibility
> of version-combinations to try is quite big.

We recently changed selinux policy to allow additional controller ports, but that doesn't impact the kernel module.

> I'll retry tomorrow to run the whole openstack packstack installation/tests
> without workaround (which is injecting selinux module to allow modules_dep_t
> / openvswitch_t / read,getattr,open ... as obtained by audit2allow) to see
> if it works now.

Ok, please keep us updated!
Thanks
fbl

Hello,
Any news here?
Thanks

I found this while looking for possible related updates in upstream/Fedora:

# rpm -qi selinux-policy-targeted
Name        : selinux-policy-targeted
Version     : 3.13.1
Release     : 128.13.fc22

ChangeLog:
[...]
* Mon Sep 14 2015 Lukas Vrabec <lvrabec> 3.13.1-128.13
- Allow openvswitch_t domains read kernel dependencies due to openvswitch run modprobe

Looks like there was an issue there, then looking back to RHEL-7 package:

commit 10c729353709901b9ea59f6b87113fe1268a5fe5
Author: Lukas Vrabec <lvrabec>
Date:   Thu Sep 10 15:25:43 2015 +0200

    * Thu Sep 10 2015 Lukas Vrabec <lvrabec> 3.13.1-48
[...]
    - Allow openvswitch_t domains read kernel dependencies due to openvswitch run modprobe

Maybe the image tested was a 7.2 devel image using an older package? At least the guest image is from Aug and the fix is from Sept.

The second attempt was made with selinux-policy -53 which contains the fix above.

You may try with selinux-policy -47 to reproduce and update to the latest to confirm the fix.

I am trying the version without the fix:

# rpm -q selinux-policy
selinux-policy-3.13.1-47.el7.noarch


type=AVC msg=audit(1446088788.733:1173): avc:  denied  { read } for  pid=23956 comm="modprobe" name="modules.dep.bin" dev="sda7" ino=800080 scontext=system_u:system_r:openvswitch_t:s0 tcontext=unconfined_u:object_r:modules_dep_t:s0 tclass=file
type=SYSCALL msg=audit(1446088788.733:1173): arch=c000003e syscall=2 success=no exit=-13 a0=7ffe6fdeaa50 a1=80000 a2=bb02d0 a3=b items=0 ppid=23932 pid=23956 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1446088788.733:1174): avc:  denied  { read } for  pid=23956 comm="modprobe" name="modules.dep.bin" dev="sda7" ino=800080 scontext=system_u:system_r:openvswitch_t:s0 tcontext=unconfined_u:object_r:modules_dep_t:s0 tclass=file
type=SYSCALL msg=audit(1446088788.733:1174): arch=c000003e syscall=2 success=no exit=-13 a0=7ffe6fde9960 a1=80000 a2=1b6 a3=3 items=0 ppid=23932 pid=23956 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1446088788.733:1175): avc:  denied  { read } for  pid=23956 comm="modprobe" name="modules.alias.bin" dev="sda7" ino=800084 scontext=system_u:system_r:openvswitch_t:s0 tcontext=unconfined_u:object_r:modules_dep_t:s0 tclass=file
type=SYSCALL msg=audit(1446088788.733:1175): arch=c000003e syscall=2 success=no exit=-13 a0=7ffe6fde9990 a1=80000 a2=1b6 a3=1 items=0 ppid=23932 pid=23956 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod" subj=system_u:system_r:openvswitch_t:s0 key=(null)


Looks like I have finally reproduced the issue.

And trying with:

# rpm -q selinux-policy
selinux-policy-3.13.1-48.el7.noarch

I can't reproduce the issue as expected.

The fix is part of RHEL-7.2 snapshot 5
http://download.devel.redhat.com/rel-eng/RHEL-7.2-Snapshot-5.0/compose/Server/x86_64/os/Packages/selinux-policy-3.13.1-60.el7.noarch.rpm

I am going to close this one.
If you need anything else, feel free to re-open it.
Thanks,
fbl