Bug 647030
| Summary: | SELinux is preventing /usr/bin/python "write" access on /etc/dhcp/manager-settings.conf. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | leigh scott <leigh123linux> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 13 | CC: | alexander.hunt2005, danchristian65, dcbw, dwalsh, jklimes, kdehairy, leigh123linux, mgrepl |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:2f3dc6a42bac64e79bf0540d86620422f83cf53ba78bfc132be4f56abcf5e51f | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-09 19:35:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
leigh scott
2010-10-26 21:18:38 UTC
*** Bug 647031 has been marked as a duplicate of this bug. *** How did you get it? What were you doing with wicd when this happened? (In reply to comment #2) > How did you get it? What were you doing with wicd when this happened? I installed selinux-policy-3.7.19-68.fc13 to fix #596982, since then I get this warning on boot up. Does networkmanager/wicd need write access to this file? NetworkManager doesn't use such file at all. It's probably wicd's config, however according to e.g. http://en.gentoo-wiki.com/wiki/Wicd, the location should be /etc/wicd/manager-settings.conf leigh, could you try to execute # restorecon -R -v /etc/wicd I think you have mislabeled files in this directory. If am wrong, please reopen the bug. (In reply to comment #6) > leigh, > > If am wrong, please reopen the bug. I'm still getting this on a clean install Leigh, Some thoughts for you: (btw, I'm just a regular user with lots of time invested in wicd issues, explaining what has worked for me; your mileage may vary :) ) There are a couple of anomalies that I have found: 1.) wicd is configured to be run by users in the 'user' group (ref comment 11, bug#608379) ; except users are not put in the 'user' group by default when the original or subsequent users are created. Try adding your username to the group 'users'. 2.) Next is that although selinux targeted policy (selinux-policy 3.9.7-16.fc14) states that the 3 files listed below should have the context: NetworkManager_var_lib_t , they didn't in my system (maybe because I didn't force a system boot-time relabel after installing the new selinux policy - I'm not sure about whether that is supposed to be done after each update or not), they just said 'Network Manager' so I fixed this with: sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wired-settings.conf sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wireless-settings.conf sudo chcon -t NetworkManager_t /etc/dhcp/manager-settings.conf 3.) Last is that /var/log/wicd.log should have its own folder to get selinux context from, so I changed that in my system so that the log is here instead: /var/log/wicd/wicd.log (ref bug#608378, comment#9) All relevant information should be somewhere in bugs #608378 and #608379 As always many Thanks to Miroslav Grepl and Daniel Walsh for their infinite patience and expertise. I hope that helps. Happy Holidays! :) (In reply to comment #7) > (In reply to comment #6) > > leigh, > > > > > If am wrong, please reopen the bug. > > > I'm still getting this on a clean install leigh, give me some outputs # ls -Z /etc/wicd/manager-settings.conf # matchpathcon /etc/wicd/manager-settings.conf
> sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wired-settings.conf
> sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wireless-settings.conf
> sudo chcon -t NetworkManager_t /etc/dhcp/manager-settings.conf
>
Alexandr,
don't use domain type for files. I mean
# chcon -t NetworkManager_t /etc/dhcp/manager-settings.conf
Also could you give me labels of these files after reboot?
Hi Miroslav, Almost time to ditch work; You should be starting holidays! lol... I realized today I made an error when I wrote: > sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wired-settings.conf > sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wireless-settings.conf > sudo chcon -t NetworkManager_t /etc/dhcp/manager-settings.conf > all 3 of those files were changed to NetworkManager_var_lib_t, not just the first two. Sorry about that; I started working on your request and noticed the error. I'd like to re-iterate item #2 of comment#8 in regards to you saying: "don't use domain type for files"; while I'm not sure which portion of the context NetworkManager_var_lib_t is the domain, I used that info because the policy says it should be that way (unless I'm misunderstanding the use of the software). I found this info in: SELinux Administration, the "File Labelling" section, sorted by SELinux File Type, scroll down to NetworkManager contexts, and look at /etc/wicd/manager-settings, wired-settings and wireless-settings. I know those files aren't in the etc/wicd folder (and they wont work there I tried it) but they are the files that wicd uses. Anyway all that is just a point of reference. Here's the info: I checked those 3 files before doing any changes. This is the context checked with root (sudo nautilus; file properties /permissions): System Configuration (That's all it says oddly enough) This is the context checked with my user account (nautilus; file properties/ permissions): system_u:object_r:etc_t:SystemLow (Better info there) It is the same context for all 3 of these files: /etc/dhcp/manager-settings.conf, etc/dhcp/wired-settings.conf, and wireless-settings.conf They were the same after a shutdown/restart. Then as per your request in comment 10; SELinux admin; put system in permissive mode temporarily to change file context to: NetworkManager_t I changed the context on all 3 files. Changed back to enforcing mode. Shutdown and start-up wicd did not start due to selinux blocking process; selinux alert: The source process /usr/bin/python Attempted this access: setattr On this file: manager-settings.conf file context on all 3 is now : system_u:object_r:NetworkManager_t:SystemLow I had to change /etc/dhcp/manager-setting.conf back to chcon -t NetworkManager_var_lib_t so that wicd sevice could start again. I left the context of /etc/dhcp/wired-settings.conf and wireless-settings.conf at NetworkManager_t and wicd is working fine with those 2 in the new context... I thought I'd throw in the info that you asked for from Leigh in case that would be of any use to you. (there's a typo in your request too, manager-settings is in /etc/dhcp, not /etc/wicd) 1.) ls -Z /etc/dhcp/manager-settings.conf -rw-------. root root system_u:object_r:NetworkManager_var_lib_t:SystemLow /etc/dhcp/manager-settings.conf 2.) matchpathcon /etc/wicd/manager-settings.conf /etc/wicd/manager-settings.conf system_u:object_r:NetworkManager_var_lib_t:SystemLow (As you will notice these were just done after I changed the context back to what allows wicd to work) I hope this info tells you something. I'm leaving for Christmas holidays now, and I will be checking email less often, but will have full access to my computer. If you need any more info or anything, don't hesitate to ask. Best wishes for the holidays Miroslav, and as always: Thank you very much for sorting this stuff out. Best regards, Alex Hi All, I thought I'd put in an end-note here. I bought myself a new hard-drive for Christmas, installed it, then installed F14-x86_64 from a fresh download of the DVD iso. I had no SELinux alerts of any kind until the system decided it needed a relabel a couple days ago, which was an easy fix with info from the new ui. Anyway I just wanted to say with a fresh install there doesn't seem to be any labelling problems with Wicd. Best wishes for all for the New Year and as always Many Thanks go out to Miroslav G. and Daniel W. Please reopen a new bug if this still happens. Thank you. |