Description of problem: /var/log/cron tells after enabling SELinux at executing an at job: ... Jun 11 00:00:00 tux atd[8884]: fgetfilecon FAILED a001cd011c6f28: No data available ... Version-Release number of selected component (if applicable): selinux-policy-targeted-1.23.18-5 How reproducible: Everytime, see below. Steps to Reproduce: 1. Disable SELinux and reboot the system 2. Submit an "at job" in the near future 3. Enable SELinux to targeted and set permissive or enforced 4. Do a "touch /.autolabel" 5. Reboot the system, wait for relabeling 6. Wait for executing of the at job, have a look to the system log 7. Will fail with the error written above. Actual results: The same problem also occurs at switching from targeted to strict and the other way round. Expected results: I'm absolutely no SELinux expert, but it seems for me, that /var/spool/at/* isn't labeled correct. I guess this can be solved in the corresponding SELinux policies...
What is the security context of the /var/spool/at? ls -lZ /var/spool/at Dan
drwx------ daemon daemon system_u:object_r:cron_spool_t . drwxr-xr-x root root system_u:object_r:var_spool_t .. -rw------- root root root:object_r:cron_spool_t .SEQ drwx------ daemon daemon system_u:object_r:cron_spool_t spool
That looks correct are you seeing any AVC messages in the log files? Dan
Nope, only what I already wrote in my first paragraph of this bug report: Jun 11 00:00:00 tux atd[8884]: fgetfilecon FAILED a001cd011c6f28: No data available
This is happening when you convert from one policy to another, correct? I think the problem is there is a file context in /var/spool/at that the new policy does not understand. The file context has this line in it. /var/spool/at/[^/]* -- <<none>> Which tells the apps not to relabel anything in the directory, because we have no idea what to relabel it to. Usually in /tmp and other places we advise deleting these files. Dan