I have an application that submits tasks to cloud services that create certain time-sensitive assets. The services take an unknown amount of time to process, and in addition the assets may be scheduled to go public even further in the future, so that I need to wait until the processing is complete and possibly longer after that until the asset is "public". At that point, I need to purge some caches to make the asset visible.
The cloud services can be passed a callback URL, so that they can notify me when the processing is complete. I have created a web service on CentOS 7 Apache that handles the callbacks. (FYI: the web service is implemented in Ruby using Passenger Phusion, with rack running on top of it.)
My idea was to have the callback schedule a system at job to purge the caches if the asset has been processed, but is not public yet.
The problem is that SELinux will not let Apache schedule an at job. Using audit2allow, I have added the following modules based on the failed operations logged in the audit.log.
ausearch -c 'unix_chkpwd' --raw | audit2allow -M my-unixchkpwd
semodule -i my-unixchkpwd.pp
ausearch -c 'at' --raw | audit2allow -M my-at
semodule -i my-at.pp
ausearch -c 'lspci' --raw | audit2allow -M my-lspci
semodule -i my-lspci.pp
The result is that now no failures are logged in audit.log, but the at command still fails.
When enforcing is on, the only thing I see in /var/log/messages is:
at: System error
Also, the standard error of the at command produces:
PAM failure: System error
But if I setenforce 0 everything works perfectly.
So even though it has to be SELinux that is preventing the at job from being scheduled, there doesn't seem to be any way to tell it to allow Apache to do it.
For now, I am having to write two different programs, one to handle assets that are public right after they are created, and another to handle assets that are scheduled at a known time in the future. If I need to handle arbitrarily scheduled assets, then I will have to implement my own version of the at scheduler. I would like to avoid such complications, if possible.
Any ideas as to how to find out what SELinux is objecting to would be appreciated (also any suggestions as to how this could be implemented without using at).
