Hide Forgot
Description of problem: A very similar denial was reported against rawhide in bug #664115; this just popped up on Fedora 15. This denial occurs when running "service libvirtd stop" or "service libvirtd start". SELinux is preventing /bin/systemd-tty-ask-password-agent from read access on the fifo_file 136:1. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that systemd-tty-ask-password-agent should be allowed read access on the 136:1 fifo_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 systemd-tty-ask /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:system_r:systemd_passwd_agent_t:s0 Target Context unconfined_u:object_r:device_t:s0 Target Objects 136:1 [ fifo_file ] Source systemd-tty-ask Source Path /bin/systemd-tty-ask-password-agent Port <Unknown> Host (removed) Source RPM Packages systemd-20-1.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-1.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux ian.icp.selfip.net 2.6.38-0.rc8.git0.1.fc15.x86_64 #1 SMP Tue Mar 8 08:22:15 UTC 2011 x86_64 x86_64 Alert Count 2 First Seen Tue 15 Mar 2011 08:57:44 AM CDT Last Seen Tue 15 Mar 2011 08:58:55 AM CDT Local ID 6928b544-aaf2-4ed5-b93f-ca79783ca1c1 Raw Audit Messages type=AVC msg=audit(1300197535.662:73): avc: denied { read } for pid=2770 comm="systemd-tty-ask" name="136:1" dev=devtmpfs ino=156243 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=fifo_file type=AVC msg=audit(1300197535.662:73): avc: denied { open } for pid=2770 comm="systemd-tty-ask" name="136:1" dev=devtmpfs ino=156243 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1300197535.662:73): arch=x86_64 syscall=open success=yes exit=ESRCH a0=1e650a0 a1=80900 a2=fffffffffffffed0 a3=6b636f6c622d6472 items=0 ppid=2769 pid=2770 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm=systemd-tty-ask exe=/bin/systemd-tty-ask-password-agent subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null) Hash: systemd-tty-ask,systemd_passwd_agent_t,device_t,fifo_file,read audit2allow #============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t device_t:fifo_file { read open }; audit2allow -R #============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t device_t:fifo_file { read open }; Version-Release number of selected component (if applicable): selinux-policy-targeted-3.9.16-1.fc15.noarch How reproducible: 100% Additional information: The pipe that systemd-tty-ask is trying to open is /dev/.systemd/ask-password-block/136:1
I guess the question then is why didn't systemd label it correctly when it created the pipe? Or is this pipe created in the kernel?
This is used by the tty and wall password agents to signal each other that where a tty agent is running a wall message doesn't need to be printed. Background: when a file system that needs to be decrypted needs a password we normally print a wall message to all logged in users informing them that the system is waiting for that, and he shall call a specific tool to enter it. However, while the user calls "systemctl" this tool will ask for the passwords anyway and hence it would be ugly if the wall message would be printed over the password prompt. We use the pipe which is named after the major/minor of the tty as flag file to communicate from systemctl (or more precisely the tty agent) to the wall agent that the tty doesn't need wall messages. We never actually send anything over the pipe. All we do is use the nice pipe behaviour that as long as nobody reads from a pipe writing to it will block/cause a failure as reliable lock. the tty agent process hence needs read access to those pipes, the wall agent write access, all though they never actually read or write to or from them. We just want the nice open() behaviour.
Since these are now under /run I am going to close.