Description of problem: It is failing on all cron jobs. SELinux patch that was written way back needs to be updated.
Created attachment 468720 [details] This patch causes cronie to ask kernel for constant definition rather then using hard coded Also add info to syslog message to help diagnose problems.
Thanks for patch, I'll add into upstream after little testing.
You might want to change the code to cache the value of "entrypoint" and "file", Since these are not likely to change during the run of cups and probing the kernel each time, is of little value. (Hopefully we do not change the flask definition until a new release. :^)
Dan, is the probing expensive?
I doubt it. Eric?
Very cheap. open() read() close() for each call. And the kernel internals of the read() is just a bit of bitshifting and masking. These values should be fixed for each kernel boot. They should not change even if policy were changed. But the overhead is very very low, so if it makes the code less complex feel free to look it up on every operation.
OK if the values are fixed for each boot it makes sense to cache them even if the lookup is cheap, i'll do that. I'm curious whether other code doesn't contain the hardcoded values as well - f.e. pam_selinux or openssh.
Theoretically, although, this is only going to happen when an app is a policy enforcer. openssh might do something around checking whether the range is "contained" within the system range.
I did not notice before but the same code as in pam_selinux is in cronie as well.
Created attachment 468967 [details] Updated patch to handle other calls This patch handles the two other times security_compute_av is called.
I've reworked the patch to cache the values for cron (not crontab, where it does not make sense). Pushed to cronie upstream git.
cronie-1.4.5-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/cronie-1.4.5-4.fc14
I'm sorry I have to reopen because I told a lie. The value can change on selinux policy update, so you really do need to recheck before every call and cannot just cache the value for the life of the system.....
Aargh, Eric :) I'm just curious why this was changed from simple constants defined in headers to strings translated to random numbers that can change on SELinux policy updates.
They have always been random numbers, we just have had control over libselinux and selinux-policy, and have worked to make sure they do not change. When they do change, either by accident or by design, then we have a problem.
Dan's right. They have always been random. Dan and I just discussed and changed SELinux policy so old cron will work with new policy, but the right thing to do is to always check the right values before the call. We'll try not to have them change in a policy from us in the future, but there is no reason a user couldn't/shouldn't make a custom policy in which it is different...
In that case the constants should be deprecated and removed from libselinux headers at some time so callers of libselinux are not confused by them.
Well I have fixed the policy in Rawhide to not cause the problem. I am not sure what the steps to tell a library that constants are no good.