Bug 608379

execute:

restorecon -Rv /var/log/wicd

*** This bug has been marked as a duplicate of bug 608378 ***

I'm getting this every time.  The restorecon doesn't fix it.  wicd dies every time on startup.

# /etc/init.d/wicd start
Starting wicd service:                                     [  OK  ]
# /etc/init.d/wicd status
wicd dead but pid file exists

Starting wicd by hand works!
# wicd
# /etc/init.d/wicd status
wicd (pid  3510) is running...

I just updated to selinux-policy 3.9.7-16.fc14.
It worked (as a system started daemon) before this update (old policy may have been several weeks old).

I'm putting the comment here, because I'm not sure it's a dup any more.

I'm on Fedora 14 x86.
uname -a
Linux tesla 2.6.35.9-64.fc14.i686.PAE #1 SMP Fri Dec 3 12:28:00 UTC 2010 i686 i686 i386 GNU/Linux

After you start wicd via the service script run 

ausearch -m avc -ts recent

FYI: I switched selinux into permissive mode, and now the daemon stays running from boot.

I get nothing after wicd is started by hand.

Here is what I get when it is started from the script:

# ausearch -m avc -ts recent
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.285:24): arch=40000003 syscall=5 success=yes exit=3 a0=9659fd0 a1=8000 a2=0 a3=0 items=0 ppid=3025 pid=3032 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="wicd" exe="/bin/bash" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.285:24): avc:  denied  { open } for  pid=3032 comm="wicd" name=".shenv" dev=sda5 ino=435 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1292359071.285:24): avc:  denied  { read } for  pid=3032 comm="wicd" name=".shenv" dev=sda5 ino=435 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.286:25): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bf9a33f4 a2=31eff4 a3=3 items=0 ppid=3025 pid=3032 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="wicd" exe="/bin/bash" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.286:25): avc:  denied  { getattr } for  pid=3032 comm="wicd" path="/root/.shenv" dev=sda5 ino=435 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.522:26): arch=40000003 syscall=5 success=yes exit=7 a0=97b7200 a1=8241 a2=1b6 a3=97b7969 items=0 ppid=1 pid=3042 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="wicd" exe="/usr/bin/python" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.522:26): avc:  denied  { write } for  pid=3042 comm="wicd" name="manager-settings.conf" dev=sda5 ino=64989 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.573:27): arch=40000003 syscall=15 success=yes exit=0 a0=97b6aa0 a1=180 a2=44dc0cc a3=9575050 items=0 ppid=1 pid=3042 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="wicd" exe="/usr/bin/python" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.573:27): avc:  denied  { setattr } for  pid=3042 comm="wicd" name="manager-settings.conf" dev=sda5 ino=64989 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file

Since this bug is closed, I have put some information that may be helpful under bug#608378

Dan, 
if you execute

restorecon -R -v /etc/wicd

does it work then? 

I mean, can you start wicd via the service script in the enforcing mode?

I did restorecon on /etc/wicd, /var/log/wicd.log and /etc/dhcp

It removes some denials, but I still get:

SELinux is preventing /usr/bin/python "write" access on
/etc/dhcp/manager-settings.conf.

Which is this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=647030

wicd still dies when started by the script, but works if started by hand.

If it matters, I completely removed NetworkManager as per Alexander Hunt's comments.  I had to fix the context on /etc/resolve.conf after the removal (many programs were having denials).

Hi Dan Christian, 
Just so you know; I am just a regular user, albeit with a long history with wicd, so be discretionary with my advice.:) I put ideas out so people can avoid some of the problems I've had. Anyway I had a thought from your comment #7; If you haven't done so already maybe try adding yourself to the group "wheel" in (Administration/Users and Groups) and then sudo visudo in terminal and un-comments lines so they look like these:

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

## Same thing without a password
%wheel          ALL=(ALL)       NOPASSWD:ALL

(The above is a bit of a security issue if you are on anything but your own personal home machine; use with caution)

If you're not familiar with vi, to edit you alt-i (I think, I use an apple kb, so if that doesn't work try the other keys in the area of "alt" + i

To escape once done taking out the # from in front of the above use the esc key.

To write is shift + : (colon or semi-colon; always forget which is which) then w + enter to write without quit or wq + enter to write and quit together. 

Anyway maybe try that and if wicd is not in your startup (Preferences/Startup applications) try adding it there. Mine works best if the system starts up wicd by itself.
Also manager-setting selinux contest on mine is: System configuration.
Same with resolve.conf. 
Feel free to email me or add here if you need any more info. Sorry if you know all this; I tend to err on the side of giving too much info rather than having people struggling with things.

I do have sudo priviledges, but I've been using "su" for all this debugging.  I find that sudo is cumbersome when you are fiddling with a bunch of stuff.  I'm not quite sure why you brought it up.  Thanks for saying too much, though.  I do the same.

I used chkconfig to enable wicd and disable NetworkManager (which has now been un-installed).

wicd is starting on boot if selinux is in permissive mode, but not in enforcing.  It will start by hand if enforcing (via su).  I can even do "daemon wicd 2> /dev/null" like the script and it works by hand (and doesn't trigger any selinux alerts).  I don't know what is different from system startup and su.

I brought it up because adding yourself to the "wheel" group makes you a part of the running system (and its privileges) instead of just a user with root privileges. The other part, allowing wheel to run any command, and then run any command without needing a password allows you to do anything the system can do without being asked for a password (for some things); Not true for anything controlled by PAM.
Anyway the problem you are having now, I had until recently as well, but now I can be in enforcing mode all the time. Check bug#659932:

Miroslav Grepl 2010-12-06 05:38:00 EST

# chcon -t NetworkManager_log_t /var/log/wicd.log 

(modified to edit context on currently running log)

Will fix.

This is where my system changed from having to be in permissive mode to working in enforcing mode.

Check bug# 608378 as well, I just added some more info there about making (hopefully) the wicd logs keep their context when they get rotated.

Dan C,
I've been working on the other issue of the logfile context changing when it's rotated and found some very interesting things.
 
1.) in this file: /usr/lib/python2.7/site-packages/wicd/wpath.py   it says:

initfile = 'init/redhat/wicd' when it is actually here: /etc/rc.d/init.d/wicd   

2.) it also says: wicd_group = 'user' - I was thinking that users aren't in the 'user' group by default, so I created a new user to check this and found I was right, and also that selinux threw the error about python not being allowed write access to /etc/dhcp/wireless-settings. Add your username to group 'user'.

3.) I found that although I am using the new selinux version, (selinux-policy 3.9.7-16.fc14), the context of  /etc/dhcp/manager-settings, wireless-settings and wired settings are not what they should be according to selinux admin app (system-config-selinux) which says they should be: NetworkManager_var_lib_t
so I did: 
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

and this one if you are adding the wicd folder to /var/log/
(as per info in bug# 608378 )
sudo chcon -t NetworkManager_log_t /var/log/wicd/

After fixing the above, doing a shutdown and startup, selinux is not throwing any errors in the new user account I made for testing.
I hope that helps.

Hi all, I've just had this issue come up again after I just updated to selinux 3.9.7-18.fc14 from the updates-testing repo, doing a boot-time relabel and starting up again.

/var/log/wicd had context reset as 'logfile' after update and relabel.
/var/log/wicd/wicd.log had context reset as 'logfile' after update and relabel.

wicd did not start with selinux call:
/usr/bin/python: attempted this access: setattr on: var/log/wicd/wicd.log

I again used:
sudo chcon -t NetworkManager_log_t /var/log/wicd
sudo chcon -t NetworkManager_log_t /var/log/wicd/wicd.log

to change context back.

Then exited Wicd Manager (GTK icon).
Then restarted wicd network manager (GTK icon) from menu (or at commandline : wicd-gtk)
Wicd connected immediately.

Daniel, in system-config-selinux / "file labelling" I created a new file specification for /var/log/wicd/wicd.* with filetype: NetworkManager_log_t:s0 and regular file, and another the same except for the new wicd directory labelled as a directory. My question is will these stay in there when the selinux policy updates come out, or are they all replaced on each update? 
Thanks again, as always, for all your help. a.

Let's clean up this bug. 

Does this still happen on F13, F14?

If so,
please open a new bug for F14 or add the comment here for F13.