Why is smokeping trying to read the /etc/shadow file?

No idea, a simple grep did not help much.

Seems strange, there should not be any need for that for pinging hosts and creating some pretty images?

Leszek, How did you get this to happen?

This happens every single time I do service smokeping start (the report was from first boot of F13 after upgrade).

If I strace -f service smokeping start OR /usr/sbin/smokeping, I can see it opening /etc/shadow. The difference is that if I just run it as root, it succeeds. If I use the start script, it fails with EACCESS and setroubleshoot pops up instead.

It reads /etc/nsswitch.conf and /lib/libnss_files.so.2 right before /etc/passwd and /etc/shadow, so I guess it's a library call from glibc. Can I somehow trap Perl script to show me a backtrace at that point?

If you run it from an init script it transitions properly,  If you run it directly it stays as an unconfined process and reads the /etc/shadow.

Does smokeping report an error?  Or does it just succeed?

Any chance smokeping uses pam?

I do not know how to debug perl.

It tries to read it on my machine also.  Does it seem to work even with this denial.  I can add a dontaudit for this access, As I don't believe it really needs it.  I have scanned the code and took a brief look at the strace and can't tell what it is doing.

Fixed in selinux-policy-3.7.19-20.fc13.noarch

I confirm it doesn't really need /etc/shadow access, or at least doesn't complain and seems working. However, actually using it results in setroubleshoot murdering my HDD (I can't believe how much this program sucks ;)). I guess raw messages are what you actually understand, as the rest is Polish anyhow, so here they go:


node=pensja.lam.pl type=AVC msg=audit(1274512544.281:2685): avc: denied { setattr } for pid=27241 comm="smokeping.cgi" name="fontconfig" dev=md127 ino=1674481 scontext=unconfined_u:system_r:httpd_smokeping_cgi_script_t:s0 tcontext=system_u:object_r:fonts_cache_t:s0 tclass=dir 

node=pensja.lam.pl type=SYSCALL msg=audit(1274512544.281:2685): arch=40000003 syscall=15 success=no exit=-13 a0=976be98 a1=1ed a2=d4d1a8 a3=976be98 items=0 ppid=25646 pid=27241 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="smokeping.cgi" exe="/usr/bin/perl" subj=unconfined_u:system_r:httpd_smokeping_cgi_script_t:s0 key=(null) 


and


node=pensja.lam.pl type=AVC msg=audit(1274512544.689:2689): avc: denied { read } for pid=25648 comm="httpd" name="Netia1_last_34560000.png" dev=md127 ino=1388795 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:smokeping_var_lib_t:s0 tclass=file 

node=pensja.lam.pl type=SYSCALL msg=audit(1274512544.689:2689): arch=40000003 syscall=5 success=no exit=-13 a0=216d778 a1=88000 a2=0 a3=1021 items=0 ppid=25636 pid=25648 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null) 


After running without enforcing (when it actually worked), one more came up:

node=pensja.lam.pl type=AVC msg=audit(1274512528.403:2666): avc: denied { read } for pid=25641 comm="httpd" name="Ping.AtorPl_last_3600.png" dev=md127 ino=1745119 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:smokeping_var_lib_t:s0 tclass=file 

node=pensja.lam.pl type=SYSCALL msg=audit(1274512528.403:2666): arch=40000003 syscall=5 success=no exit=-13 a0=216d738 a1=88000 a2=0 a3=1021 items=0 ppid=25636 pid=25641 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null) 


I'm a SELinux noob ;) so of course I might be doing something wrong, please excuse me in that case.

Hi guys,
to sum it up:
 o smokeping for unknown reason reads /etc/passwd (via some library call?)
 o selinux-policy adds donaudit to "fix" the issue
 o setroubleshoot is still complaining and trashing the hard drive?

Could you attach the output from 

# ausearch -m avc -ts recent

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.