Bug 523875 - selecting "Use this connection only ..." does not stay selected
selecting "Use this connection only ..." does not stay selected
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F12Target
  Show dependency treegraph
 
Reported: 2009-09-16 19:45 EDT by Gene Czarcinski
Modified: 2009-10-13 15:11 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-10 16:39:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Gene Czarcinski 2009-09-16 19:45:41 EDT
Description of problem:
I am running Fedora 11 as a qemu-kvm guest on a Fedora 11 host.

I also have Fedora 12 alpha+updates as a qemu-kvm guest running on a Fedora 12 alpha+updates host.

I create/install Fedora on a qemu-kvm guest with on (regular/default) NAT NIC (192.168.122.0/24 network on eth1).  This boots and runs fine.

I then add a second (private virtual network) NIC (192.168.217.0/24 on eth2) NIC and reboot.  NM recognizes and brings up both NICs.

Since I DO NOT want eth2 to be the default route, I edit the configuration via nm (gnome) applet and select "Use this connection only for resources on its network".  I then apply the change.  However, when I edit it again, "Use this connection ..." is NOT selected.

This occurs on both systems cited below.

Yes, this is the same problem I have mentioned on the networkmanager mailing list.

Version-Release number of selected component (if applicable):

Fedora 11, NetworkManager-0.7.1-8.git20090708.fc11.x86_64

Fedora 1 alpha + updates, NetworkManager-0.7.996-1.git20090826.fc12.x86_64

How reproducible:
Every time
Comment 1 Gene Czarcinski 2009-09-23 10:45:16 EDT
Oops ... this should be reported against Fedora 11
Comment 3 Gene Czarcinski 2009-09-28 17:30:16 EDT
Since https://bugzilla.redhat.com/show_bug.cgi?id=525762 was closed as a dup of this report, I am marking this report as an F12Target blocker ... this report is against F11 and 525762 was against F12-rawhide.

If I have eth0=NAT-to-Internet and eth1=private, then F11 pretty much gets the route wrong (default route is set to eth1).  On the other hand with F12-rawhide and with eth0=NET-to-Internet/eth1=private, the default route is correctly set to eth0 ... this must be "luck" which is why I am setting this as F12Target blocker.

On F12-rawhide, if I re-do the NIC definitions so that eth0=private and eth1=NAT-to-Internet, then the route is wrong with the default set to eth0 (in this case, the default needs to be set to eth1).

The fix is to use the "route check box" but that does not work because (apparently) selinux prevents "unlink".
Comment 4 Gene Czarcinski 2009-09-28 18:31:22 EDT
Below is the selinx alert text from a f11 qemu-kvm guest (eth0 is a bridge NIC rather than NAT but that should make no difference).

-------------------------------
Summary:

SELinux is preventing nm-system-setti (NetworkManager_t) "unlink" to
/etc/NetworkManager/nm-system-settings.conf (etc_t).

Detailed Description:

SELinux is preventing nm-system-setti (NetworkManager_t) "unlink" to
/etc/NetworkManager/nm-system-settings.conf (etc_t). The SELinux type etc_t, is
a generic type for all files in the directory and very few processes (SELinux
Domains) are allowed to write to this SELinux type. This type of denial usual
indicates a mislabeled file. By default a file created in a directory has the
gets the context of the parent directory, but SELinux policy has rules about the
creation of directories, that say if a process running in one SELinux Domain
(D1) creates a file in a directory with a particular SELinux File Context (F1)
the file gets a different File Context (F2). The policy usually allows the
SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for
some reason a file (/etc/NetworkManager/nm-system-settings.conf) was created
with the wrong context, this domain will be denied. The usual solution to this
problem is to reset the file context on the target file, restorecon -v
'/etc/NetworkManager/nm-system-settings.conf'. If the file context does not
change from etc_t, then this is probably a bug in policy. Please file a bug
report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the
selinux-policy package. If it does change, you can try your application again to
see if it works. The file context could have been mislabeled by editing the file
or moving the file from a different directory, if the file keeps getting
mislabeled, check the init scripts to see if they are doing something to
mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v
'/etc/NetworkManager/nm-system-settings.conf'

Fix Command:

restorecon '/etc/NetworkManager/nm-system-settings.conf'

Additional Information:

Source Context                system_u:system_r:NetworkManager_t:s0-s0:c0.c1023
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc/NetworkManager/nm-system-settings.conf [ file
                              ]
Source                        nm-system-setti
Source Path                   /usr/sbin/nm-system-settings
Port                          <Unknown>
Host                          f11test1
Source RPM Packages           NetworkManager-0.7.1-8.git20090708.fc11
Target RPM Packages           NetworkManager-0.7.1-8.git20090708.fc11
Policy RPM                    selinux-policy-3.6.12-80.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   mislabeled_file
Host Name                     f11test1
Platform                      Linux f11test1 2.6.30.5-43.fc11.x86_64 #1 SMP Thu
                              Aug 27 21:39:52 EDT 2009 x86_64 x86_64
Alert Count                   2
First Seen                    Mon 28 Sep 2009 10:06:31 PM EDT
Last Seen                     Mon 28 Sep 2009 10:06:38 PM EDT
Local ID                      9774e5dd-99ad-448d-84f6-8a69d3c9459c
Line Numbers                  

Raw Audit Messages            

node=f11test1 type=AVC msg=audit(1254189998.579:27): avc:  denied  { unlink } fo
r  pid=1799 comm="nm-system-setti" name="nm-system-settings.conf" dev=vda3 ino=1
10851 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system
_u:object_r:etc_t:s0 tclass=file

node=f11test1 type=SYSCALL msg=audit(1254189998.579:27): arch=c000003e syscall=8
2 success=no exit=-13 a0=237e860 a1=2372250 a2=23e11b0 a3=1 items=0 ppid=1 pid=1
799 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=
(none) ses=4294967295 comm="nm-system-setti" exe="/usr/sbin/nm-system-settings" 
subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 key=(null)


----------------------------------------------------
Comment 5 Daniel Walsh 2009-09-29 08:08:19 EDT
If you 

chcon -R -t NetworkManager_var_lib_t /etc/NetworkManager

Does everything work?  Do you see any other problems?
Comment 6 Gene Czarcinski 2009-09-29 12:15:17 EDT
I ran the "chcon" command on both F11 and an F12-rawhide qemu-kvm guests.

In both cases, no problems with selinx.  In both cases, it still did not work (that is, the "... use connection only ..." checkbox does not stay checked and the default route is still incorrect.

A question for Dan and Daniel ... Since I am using qemu-kvm guests, I would think that you could create these for yourselves.  On the other hand, I can understand that you may be simply too busy with other things to setup tests for this problem.

Since setroubleshoot is not currently working on F12-rawhide, I was monitoring /var/log/messages and saw some interesting messages which may be relevant.  As soon as I can capture them, I will add thhem to this report.
Comment 7 Gene Czarcinski 2009-10-04 17:31:18 EDT
Another piece of information ...

I brought up a qemu-kvm F12 guest in init mode 3.  I then logged on as root and did startx.

OK, I am now running gnome gui as root so there should be no issues with permissions.  I go through trying to check the "connection only" box and it does not stick.

To me, this says that the code is never saving the value or saving it to the wrong place.
Comment 8 Gene Czarcinski 2009-10-08 14:17:49 EDT
1. For F12, adding GATEWAYDEV=ethX to /etc/sysconfig/network is a work-around for setting the correct route (and getting th "connectrion only" checkbox checked.

2. On F12, nm-connections-editor still does not work for adding/removing GATEWAYDEV=

3. Using the GATEWAYDEV-ethX solution on F11 does NOT work!
Comment 9 Gene Czarcinski 2009-10-10 16:39:27 EDT
I have opened a new BZ report: https://bugzilla.redhat.com/show_bug.cgi?id=528281 which replaces this report.  I am closing this report as "WONTFIX" and am putting my efforts into seeing the problem fixed post F12 release.

Note You need to log in before you can comment on or make changes to this bug.