selinux-policy version: selinux-policy-3.0.8-58.fc8 Description of problem: SSHD get access denied for file /var/log/btmp Security context for /var/log/btmp: system_u:object_r:var_log_t:s0 SSHD using system_u:system_r:sshd_t:s0-s0:c0.c1023 Steps to Reproduce: 1. Run sshd 2. From other machine connect to sshd. 3. Enter wrong user and password. Actual results: Access denied for sshd. Expected results: Access for writing.
Some how the file context on btmp got lost restorecon /var/log/btmp should fix. If you have any idea what removed and recreated this file, tell me. This is not a bug in selinux but in the package that removed and recreated the file.
The same thing happened to me. My guess is that logrotate did this. [root@gap psavola]# restorecon -n -v /var/log/btmp-20080101 [root@gap psavola]# restorecon -n -v /var/log/btmp restorecon reset /var/log/btmp context system_u:object_r:var_log_t:s0->system_u:object_r:faillog_t:s0 But I'm not sure if that's conclusive. There seems to be another bug with logrotate-related selinux policies. At F8, by default the rotated files are no longer "name.[0-9]*" format but "name-[date]" format, and the policy doesn't seem to reflect this (grep -r btmp under /etc/selinux yield e.g., 'modules/active/file_contexts:/var/log/btmp.*').
Oops, two similar looking SSHD AVCs, the symptoms are already described in #427274. Maybe that was also the cause for losing the context here..