Description of problem: avc: denied { getattr } for comm="pam_console_app" dev=dm-0 name="/" pid=318276 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023 tclass=filesystem tcontext=system_u:object_r:fs_t:s0 Version-Release number of selected component (if applicable): pam-0.99.6.2-3.9.fc6
what happens if you do 'restorecon /'? What is printed by ls -Zd / before and after the restorecon?
# ls -Zd / drwxr-xr-x root root system_u:object_r:root_t / # restorecon / # ls -Zd / drwxr-xr-x root root system_u:object_r:root_t /
Strange that / has correct system_u:object_r:root_t but in the AVC it shows system_u:object_r:fs_t. I don't see this problem here. pam_console_apply must be able to getattr on '/' so that's rather a policy or labelling issue of some kind.
*** This bug has been marked as a duplicate of 222806 ***
The '/' in the AVC is not the real root but a root of the filesystem on dev dm-0. What is the content of the /etc/fstab and what 'ls -l /dev/mapper' prints?
$ cat /etc/fstab /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 ##/dev/VolGroup00/LogVol01 swap swap defaults 0 0 # MY: /swap swap swap defaults 0 0 $ ls -l /dev/mapper total 0 crw------- 1 root root 10, 63 Jan 25 15:49 control brw-rw---- 1 root disk 253, 0 Jan 25 15:50 VolGroup00-LogVol00 brw-rw---- 1 root disk 253, 1 Jan 25 15:49 VolGroup00-LogVol01
You are right, of course, but the filesystem on dm-0 *is* the one mounted on /
Ah yes, that's because it is not a label of the root dir on the filesystem but of the filesystem object itself. So the bug 222806 can actually be closed as NOTABUG. I am reopening this one. Can you try to run pam_console_apply manually from a root account with and without '-r' option? Do the AVCs appear? If yes, can you please strace pam_console_apply and attach the log here?
I have run 'pam_console_apply' and 'pam_console_apply -r' from a root prompt opened with 'su -'. No AVCs. I only got the AVC in regard to pam_console_apply 2 times. But from webalizer: 142 times. Webalizer is a daily cronjob, but sometimes there is no AVC for days (the cronjob does get run)... So I will try running pam_console_apply more... In the meantime I tried running './00webalizer' in /etc/cron.daily and got the AVC that is in bug 222806 .
Created attachment 146883 [details] Output of 'strace -fF ./00webalizer' in /etc/cron.daily as root
What exactly is that strace output supposed to show? What is webalizer doing wrong?
Well this strace doesn't seem to do anything suspicious to me. We would need a strace when the AVC happen.
That straced webalizer produced an avc. avc: denied { getattr } for comm="webalizer" dev=dm-0 name="/" pid=18041 scontext=user_u:system_r:webalizer_t:s0 tclass=filesystem tcontext=system_u:object_r:fs_t:s0 The PID matches.
Sorry but what syscall does "getattr" correspond to? stat and variants? I can not reproduce this with pam_console_apply even after policy packge upgrade (which seemed to trigger this "issue" with setroubleshootd and webalizer) it runs without avcs... I tried by downgrading to an old policy and upgrading again.
I cannot reproduce this issue any more.
perhaps this was resolved with some later policy upgrade
And just the following day, I got this again... Now it's tzdata avc: denied { getattr } for comm="tzdata-update" dev=dm-0 name="/" pid=9902 scontext=system_u:system_r:tzdata_t:s0 tclass=filesystem tcontext=system_u:object_r:fs_t:s0
This really looks like some leaked descriptor. But which process leaks it...