RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1365653 - Failure to configure team with ifcfg
Summary: Failure to configure team with ifcfg
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.3
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: 1366991 1367180
TreeView+ depends on / blocked
 
Reported: 2016-08-09 18:30 UTC by Amit Supugade
Modified: 2016-11-04 02:36 UTC (History)
12 users (show)

Fixed In Version: selinux-policy-3.13.1-95.el7
Doc Type: Bug Fix
Doc Text:
It is not known issue anymore, fixed in selinux-policy-3.13.1-95.el7
Clone Of:
: 1367180 (view as bug list)
Environment:
Last Closed: 2016-11-04 02:36:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2283 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2016-11-03 13:36:25 UTC

Description Amit Supugade 2016-08-09 18:30:08 UTC 
Description of problem:
Failure to configure team with ifcfg

Version-Release number of selected component (if applicable):
libteam-1.25-2.el7.x86_64
teamd-1.25-2.el7.x86_64


How reproducible:
Always

Steps to Reproduce:
1.
cat <<-EOF > /etc/sysconfig/network-scripts/ifcfg-enp7s0f0
DEVICE=enp7s0f0
ONBOOT=no
TEAM_MASTER=team0
EOF

2.
cat <<-EOF > /etc/sysconfig/network-scripts/ifcfg-enp7s0f1
DEVICE=enp7s0f1
ONBOOT=no
TEAM_MASTER=team0
EOF

3.
cat <<-EOF > /etc/sysconfig/network-scripts/ifcfg-team0
DEVICE=team0
ONBOOT=no
BOOTPROTO=none
IPADDR=192.168.23.11
NETMASK=255.255.255.0
TEAM_CONFIG='{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'
EOF

4.
ifup team0


Actual results:
ifup team0
Error: Connection activation failed: No suitable device found for this connection.

Expected results:
team device should become available

Additional info:
Comment 12 Milos Malik 2016-08-18 14:59:29 UTC 
The /run/teamd/team0.conf file is mislabeled. Following command will fix it:

# restorecon -Rv /run/teamd

Does the scenario work now?
Comment 13 Marcelo Ricardo Leitner 2016-08-18 15:01:29 UTC 
(In reply to Milos Malik from comment #12)
> The /run/teamd/team0.conf file is mislabeled. Following command will fix it:

Sorry for my ignorance on the topic but assuming that's it, how can we avoid this? Was the file created in a wrong way?
Comment 14 Milos Malik 2016-08-18 15:09:09 UTC 
We have to find out which process created the /run/teamd directory and which process created the team0.conf file. Files inside /run/teamd directory should inherit the same SELinux label unless selinux-policy tells otherwise. Did it happen on a clean machine?
Comment 15 Xin Long 2016-08-18 15:58:06 UTC 
(In reply to Milos Malik from comment #14)
> We have to find out which process created the /run/teamd directory and which
> process created the team0.conf file. Files inside /run/teamd directory
> should inherit the same SELinux label unless selinux-policy tells otherwise.
> Did it happen on a clean machine?

Hi, Milos

When we run "ifup team0", the current shell process calls:
/etc/sysconfig/network-scripts/ifup-Team, in it:

	mkdir -p /run/teamd/  || exit 1
	echo "${TEAM_CONFIG}" > /run/teamd/${DEVICE}.conf  || exit 1
	/usr/bin/systemctl start teamd@${DEVICE}.service  || exit 1 <----[1]

(${DEVICE} is team0 here)

So current shell process create this directory and file.
ls -Z "/run/teamd/team0.conf"
-rw-r--r--. root root unconfined_u:object_r:var_run_t:s0 /run/teamd/team0.conf

However, [1] will send a request to systemd, then
systemd process starts teamd daemon with:
/usr/bin/teamd -U -D -o -t %i -f /run/teamd/%i.conf
(%i is team0 here)

So systemd process access this file.

[root@localhost ~]# ps axZ |grep systemd
system_u:system_r:init_t:s0         1 ?        Ss     0:20 /usr/lib/systemd/systemd --switched-root --system --deserialize 21

---------
If we config "BOOT=yes" in team configuration, it works fine, as network service
call ifup-Team and create the directory and the file when system is booting.

But if we config "BOOT=no" in team configuration, network will not call it.then
we may use ifup team0 to start it manually in an shell terminal, then this issue
is triggered.
Comment 16 Amit Supugade 2016-08-18 17:11:22 UTC 
(In reply to Milos Malik from comment #12)
> The /run/teamd/team0.conf file is mislabeled. Following command will fix it:
> 
> # restorecon -Rv /run/teamd
> 
> Does the scenario work now?
This command did not fix it. I saw the same behaviour as before.
Comment 17 Milos Malik 2016-08-18 21:02:15 UTC 
Which version of selinux-policy do you have on your machine?

# rpm -qa selinux-policy\*
Comment 18 Amit Supugade 2016-08-18 21:07:49 UTC 
(In reply to Milos Malik from comment #17)
> Which version of selinux-policy do you have on your machine?
> 
> # rpm -qa selinux-policy\*

[root@sam ~]# rpm -qa selinux-policy\*
selinux-policy-targeted-3.13.1-93.el7.noarch
selinux-policy-3.13.1-93.el7.noarch
Comment 19 Milos Malik 2016-08-18 21:32:47 UTC 
There is one test case among selinux-policy tests which is dedicated to teamd:
* /CoreOS/selinux-policy/Regression/teamd-and-similar

The /run/teamd directory did not exist on my VMs before running the test case. After running the test case I see following. The directory is labeled correctly.

# rpm -qf /run/teamd/
file /run/teamd is not owned by any package
# ls -dZ /run/teamd/
drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0 /run/teamd/
#

Could you remove the /run/teamd directory first, run your scenario and then provide output of following commands?

# ls -Z /run/teamd
Comment 20 Amit Supugade 2016-08-18 21:43:28 UTC 
(In reply to Milos Malik from comment #19)
> There is one test case among selinux-policy tests which is dedicated to
> teamd:
> * /CoreOS/selinux-policy/Regression/teamd-and-similar
> 
> The /run/teamd directory did not exist on my VMs before running the test
> case. After running the test case I see following. The directory is labeled
> correctly.
> 
> # rpm -qf /run/teamd/
> file /run/teamd is not owned by any package
> # ls -dZ /run/teamd/
> drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0
> /run/teamd/
> #
> 
> Could you remove the /run/teamd directory first, run your scenario and then
> provide output of following commands?
> 
> # ls -Z /run/teamd
Here is the output of the command as requested-
[root@sam run]# ls -Z /run/teamd
-rw-r--r--. root root system_u:object_r:NetworkManager_var_run_t:s0 team0.pid
srwx------. root root system_u:object_r:NetworkManager_var_run_t:s0 team0.sock
Comment 21 Xin Long 2016-08-19 06:50:36 UTC 
Hi
(In reply to Milos Malik from comment #19)
> There is one test case among selinux-policy tests which is dedicated to
> teamd:
> * /CoreOS/selinux-policy/Regression/teamd-and-similar
> 
> The /run/teamd directory did not exist on my VMs before running the test
> case. After running the test case I see following. The directory is labeled
> correctly.
> 
> # rpm -qf /run/teamd/
> file /run/teamd is not owned by any package
> # ls -dZ /run/teamd/
> drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0
> /run/teamd/
> #
> 
> Could you remove the /run/teamd directory first, run your scenario and then
> provide output of following commands?
> 
> # ls -Z /run/teamd
Pls disable NM, this issue happens without NM.
Comment 22 Xin Long 2016-08-19 06:53:12 UTC 
(In reply to Amit Supugade from comment #20)
> (In reply to Milos Malik from comment #19)
> > There is one test case among selinux-policy tests which is dedicated to
> > teamd:
> > * /CoreOS/selinux-policy/Regression/teamd-and-similar
> > 
> > The /run/teamd directory did not exist on my VMs before running the test
> > case. After running the test case I see following. The directory is labeled
> > correctly.
> > 
> > # rpm -qf /run/teamd/
> > file /run/teamd is not owned by any package
> > # ls -dZ /run/teamd/
> > drwxr-xr-x. root root system_u:object_r:NetworkManager_var_run_t:s0
> > /run/teamd/
> > #
> > 
> > Could you remove the /run/teamd directory first, run your scenario and then
> > provide output of following commands?
> > 
> > # ls -Z /run/teamd
> Here is the output of the command as requested-
> [root@sam run]# ls -Z /run/teamd
> -rw-r--r--. root root system_u:object_r:NetworkManager_var_run_t:s0 team0.pid
> srwx------. root root system_u:object_r:NetworkManager_var_run_t:s0
> team0.sock

without NM, it should be:
ls -Z "/run/teamd/team0.conf"
-rw-r--r--. root root unconfined_u:object_r:var_run_t:s0 /run/teamd/team0.conf
                 -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Comment 23 Miroslav Grepl 2016-08-22 09:34:00 UTC 
Milos,
are you able to reproduce it?
Comment 24 Miroslav Grepl 2016-08-22 09:36:24 UTC 
Guys,
how is /run/teamd created?
Comment 25 Xin Long 2016-08-22 10:24:53 UTC 
(In reply to Miroslav Grepl from comment #24)
> Guys,
> how is /run/teamd created?

Miroslav, pls check c15 .
Comment 26 Miroslav Grepl 2016-08-22 14:00:00 UTC 
Ok, I overlooked. Thanks.

So it happens because of


>But if we config "BOOT=no" in team configuration, network will not call it.then
>we may use ifup team0 to start it manually in an shell terminal, then this issue
>is triggered.

Could you please test it with the following local policy?

$ cat mypol.cil
(typetransition unconfined_t var_run_t dir "teamd" NetworkManager_var_run_t)
# semodule -i mypol.cil

to see if it works correctly?

Thank you.
Comment 27 Jaroslav Aster 2016-08-22 14:22:42 UTC 
Hi,

today, I found out same issue in my test, but only on aarch64. Other architectures work fine. I use nmcli in my test, but it fails without nmcli too.

# rpm -q selinux-policy kernel
selinux-policy-3.13.1-93.el7.noarch
kernel-4.5.0-3.el7.aarch64

# ausearch -m avc -m user_avc -m selinux_err -i -ts recent
<no matches>

# nmcli connection add con-name teamTest ifname teamTest type team config '{"runner": {"name": "activebackup"}}'
Connection 'teamTest' (effd6db2-5189-4c69-ba1e-ce67a76c75b4) successfully added.

# ausearch -m avc -m user_avc -m selinux_err -i -ts recent
----
type=PROCTITLE msg=audit(08/22/2016 10:05:51.376:449) : proctitle=/usr/bin/teamd -o -n -U -D -N -t teamTest -c {"runner": {"name": "activebackup"}} 
type=SYSCALL msg=audit(08/22/2016 10:05:51.376:449) : arch=aarch64 syscall=socket success=no exit=EACCES(Permission denied) a0=netlink a1=SOCK_RAW a2=chaos a3=0x3fff1deae30 items=0 ppid=764 pid=28763 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=teamd exe=/usr/bin/teamd subj=system_u:system_r:NetworkManager_t:s0 key=(null) 
type=AVC msg=audit(08/22/2016 10:05:51.376:449) : avc:  denied  { create } for  pid=28763 comm=teamd scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=netlink_generic_socket permissive=0 
----
type=PROCTITLE msg=audit(08/22/2016 10:05:51.716:450) : proctitle=/usr/bin/teamd -o -n -U -D -N -t teamTest -c {"runner": {"name": "activebackup"}} 
type=SYSCALL msg=audit(08/22/2016 10:05:51.716:450) : arch=aarch64 syscall=socket success=no exit=EACCES(Permission denied) a0=netlink a1=SOCK_RAW a2=chaos a3=0x3ffd7e99200 items=0 ppid=764 pid=28767 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=teamd exe=/usr/bin/teamd subj=system_u:system_r:NetworkManager_t:s0 key=(null) 
type=AVC msg=audit(08/22/2016 10:05:51.716:450) : avc:  denied  { create } for  pid=28767 comm=teamd scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=netlink_generic_socket permissive=0 
----
type=PROCTITLE msg=audit(08/22/2016 10:05:52.047:451) : proctitle=/usr/bin/teamd -o -n -U -D -N -t teamTest -c {"runner": {"name": "activebackup"}} 
type=SYSCALL msg=audit(08/22/2016 10:05:52.047:451) : arch=aarch64 syscall=socket success=no exit=EACCES(Permission denied) a0=netlink a1=SOCK_RAW a2=chaos a3=0x3fffbd6f2e0 items=0 ppid=764 pid=28771 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=teamd exe=/usr/bin/teamd subj=system_u:system_r:NetworkManager_t:s0 key=(null) 
type=AVC msg=audit(08/22/2016 10:05:52.047:451) : avc:  denied  { create } for  pid=28771 comm=teamd scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=netlink_generic_socket permissive=0 
----
type=PROCTITLE msg=audit(08/22/2016 10:05:52.382:452) : proctitle=/usr/bin/teamd -o -n -U -D -N -t teamTest -c {"runner": {"name": "activebackup"}} 
type=SYSCALL msg=audit(08/22/2016 10:05:52.382:452) : arch=aarch64 syscall=socket success=no exit=EACCES(Permission denied) a0=netlink a1=SOCK_RAW a2=chaos a3=0x3ffc9913c40 items=0 ppid=764 pid=28775 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=teamd exe=/usr/bin/teamd subj=system_u:system_r:NetworkManager_t:s0 key=(null) 
type=AVC msg=audit(08/22/2016 10:05:52.382:452) : avc:  denied  { create } for  pid=28775 comm=teamd scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=netlink_generic_socket permissive=0
Comment 28 Amit Supugade 2016-08-22 15:36:25 UTC 
(In reply to Miroslav Grepl from comment #26)
> Ok, I overlooked. Thanks.
> 
> So it happens because of
> 
> 
> >But if we config "BOOT=no" in team configuration, network will not call it.then
> >we may use ifup team0 to start it manually in an shell terminal, then this issue
> >is triggered.
> 
> Could you please test it with the following local policy?
> 
> $ cat mypol.cil
> (typetransition unconfined_t var_run_t dir "teamd" NetworkManager_var_run_t)
> # semodule -i mypol.cil
> 
> to see if it works correctly?
> 
> Thank you.

Hi,
I tried with the local policy and it worked fine. Log below-

[root@robin ~]# cat mypol.cil
(typetransition unconfined_t var_run_t dir "teamd" NetworkManager_var_run_t)
[root@robin ~]# systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2016-08-22 11:33:10 EDT; 2s ago
     Docs: man:NetworkManager(8)
 Main PID: 817 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/NetworkManager.service
           └─879 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-enp5s0f0.pid -lf /var/lib/NetworkManager/dhclient-0bb2b557-70e0-4f3f-b3d2-4c4335f91...

Aug 22 11:26:58 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879618.5664] device (enp7s0f0): link disconnected
Aug 22 11:26:58 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879618.5671] device (enp7s0f1): link disconnected
Aug 22 11:31:03 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879863.1986] device (enp7s0f1): link connected
Aug 22 11:31:04 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879864.2008] device (enp7s0f1): link disconnected
Aug 22 11:31:28 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879888.3075] device (enp7s0f1): link connected
Aug 22 11:31:29 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879889.2921] device (enp7s0f0): link connected
Aug 22 11:33:10 robin.knqe.lab.eng.bos.redhat.com systemd[1]: Stopping Network Manager...
Aug 22 11:33:10 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879990.2194] caught SIGTERM, shutting down normally.
Aug 22 11:33:10 robin.knqe.lab.eng.bos.redhat.com NetworkManager[817]: <info>  [1471879990.2227] exiting (success)
Aug 22 11:33:10 robin.knqe.lab.eng.bos.redhat.com systemd[1]: Stopped Network Manager.
[root@robin ~]# 
[root@robin ~]# semodule -i mypol.cil
[root@robin ~]# cat <<-EOF > /etc/sysconfig/network-scripts/ifcfg-enp7s0f0
> DEVICE=enp7s0f0
> ONBOOT=no
> TEAM_MASTER=team0
> EOF
[root@robin ~]# 
[root@robin ~]# cat <<-EOF > /etc/sysconfig/network-scripts/ifcfg-enp7s0f1
> DEVICE=enp7s0f1
> ONBOOT=no
> TEAM_MASTER=team0
> EOF
[root@robin ~]# 
[root@robin ~]# 
[root@robin ~]# cat <<-EOF > /etc/sysconfig/network-scripts/ifcfg-team0
> DEVICE=team0
> ONBOOT=no
> BOOTPROTO=none
> IPADDR=192.168.23.11
> NETMASK=255.255.255.0
> TEAM_CONFIG='{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'
> EOF
[root@robin ~]# 
[root@robin ~]# ifup team0

[root@robin ~]# 
[root@robin ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp7s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master team0 state UP qlen 1000
    link/ether 00:90:fa:8a:5c:7a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::290:faff:fe8a:5c7a/64 scope link 
       valid_lft forever preferred_lft forever
3: enp5s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e4:11:5b:dd:d6:06 brd ff:ff:ff:ff:ff:ff
    inet 10.19.15.27/24 brd 10.19.15.255 scope global dynamic enp5s0f0
       valid_lft 84345sec preferred_lft 84345sec
    inet6 2620:52:0:130b:e611:5bff:fedd:d606/64 scope global noprefixroute dynamic 
       valid_lft 2591822sec preferred_lft 604622sec
    inet6 fe80::e611:5bff:fedd:d606/64 scope link 
       valid_lft forever preferred_lft forever
4: enp7s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master team0 state UP qlen 1000
    link/ether 00:90:fa:8a:5c:7a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::290:faff:fe8a:5c82/64 scope link 
       valid_lft forever preferred_lft forever
5: enp5s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether e4:11:5b:dd:d6:07 brd ff:ff:ff:ff:ff:ff
6: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 00:90:fa:8a:5c:7a brd ff:ff:ff:ff:ff:ff
    inet 192.168.23.11/24 brd 192.168.23.255 scope global team0
       valid_lft forever preferred_lft forever
    inet6 2001::290:faff:fe8a:5c7a/64 scope global mngtmpaddr dynamic 
       valid_lft 2591999sec preferred_lft 604799sec
    inet6 fe80::290:faff:fe8a:5c7a/64 scope link 
       valid_lft forever preferred_lft forever
Comment 29 Amit Supugade 2016-08-22 19:11:34 UTC 
This bug is causing many other team test failures. Increasing Priority and Severity.
Comment 30 Miroslav Grepl 2016-08-23 07:28:18 UTC 
Ok we have tested fix.

(typetransition unconfined_t var_run_t dir "teamd" NetworkManager_var_run_t)
(allow NetworkManager_t NetworkManager_t ( netlink_generic_socket ( create )))
Comment 36 errata-xmlrpc 2016-11-04 02:36:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2283.html
Note You need to log in before you can comment on or make changes to this bug.