Hide Forgot
SELinux is preventing /usr/kerberos/sbin/klogind from read, write access on the chr_file 7. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that klogind should be allowed read write access on the 7 chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep klogind /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:rlogind_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:user_devpts_t:s0 Target Objects 7 [ chr_file ] Source klogind Source Path /usr/kerberos/sbin/klogind Port <Unknown> Host (removed) Source RPM Packages krb5-appl-servers-1.0.1-3.fc14.1 Target RPM Packages Policy RPM selinux-policy-3.9.7-40.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.37.3+ #1 SMP Tue Mar 8 20:44:41 GMT 2011 i686 i686 Alert Count 2 First Seen Mon 02 May 2011 12:10:26 BST Last Seen Mon 02 May 2011 12:10:34 BST Local ID 0198a532-3443-4788-a24a-12c2ca1402c7 Raw Audit Messages type=AVC msg=audit(1304334634.573:1925): avc: denied { read write } for pid=32271 comm="klogind" name="7" dev=devpts ino=10 scontext=system_u:system_r:rlogind_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=SYSCALL msg=audit(1304334634.573:1925): arch=i386 syscall=open success=no exit=EACCES a0=b775cfe0 a1=8002 a2=0 a3=b775cfe0 items=0 ppid=27108 pid=32271 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=klogind exe=/usr/kerberos/sbin/klogind subj=system_u:system_r:rlogind_t:s0-s0:c0.c1023 key=(null) Hash: klogind,rlogind_t,user_devpts_t,chr_file,read,write audit2allow #============= rlogind_t ============== allow rlogind_t user_devpts_t:chr_file { read write }; audit2allow -R #============= rlogind_t ============== allow rlogind_t user_devpts_t:chr_file { read write };
Does it happen by default? Or any chance you ran restorecon?
We probably should allow this,
Not sure what it is doing though. Does this happen when you are logging out or while you are logging in? After you log in is the tty 7? $ tty
To comment #1: no, I didn't run restorecon. To comment #7: yes, tty 7 is the tty which _was_ logged in. It appears to only happen when the session unexpectedly dies (eg, because the end running krsh went away and the tcp connection timed out.) It can be caused by logging in, and then killing the 'rsh' process on the originating machine.
Miroslav lets allow.
Fixed in selinux-policy-3.9.7-41.fc14
selinux-policy-3.9.7-42.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-42.fc14
Package selinux-policy-3.9.7-42.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.7-42.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-42.fc14 then log in and leave karma (feedback).
selinux-policy-3.9.7-42.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.