Hardware Reference
In-Depth Information
Controlling the Machine
Although Apache is capable of running scripts dynamically when web pages are requested, they are done so as the
user under which Apache runs. Depending on your configuration, this is usually the
www-data
or
nobody
user. Confirm
this by including the following
whoami.php
script on your web server and then loading it in a browser:
<?php
system("whoami");
?>
Consider this user carefully. Because all system calls made by the server (on behalf of the user accessing the web
page) will happen as
www-data
, there are further considerations to the code being run:
u
This user probably has more access to your file system than you expect. No longer does
someone need a user account on the Linux machine to read the filesystem; they can do so
through the web page if there are security issues with the software or its configuration.
u
Also, the permissions will be different, not just for the necessary configuration files but the
access rights to devices, such as the CD-ROM or sound card. If you allow a web page to control
your CD-ROM, for example, then
/dev/cdrom
must have read-write access granted for the
www-data
user. Because this is a little specific, it is more usual to grant read-write permission
to an audio group and add user
www-data
to that group. Note that you have to restart the
Apache server whenever such a change to their user's group is made. The same is true for
access to
/dev/dsp
.
u
The path used to determine the location of named executables will be significantly different
from that of your normal user that you have tested with. This means you should explicitly use
the path in all commands issued.
u
The environment variables will also be different. You may need to set these up manually by
logging in as the Apache user (for example,
rlogin www-data@localhost
) and setting up the
environment accordingly. You can also use this approach to confirm that your permissions
are correctly set by running the commands manually. This also allows you to create any
configuration files that might be necessary.
u
Finally, remember that most system commands are blocking. That is, they don't return until
they've finished their task. So, when the task is being called from inside a web page, the
user will be at a blank web page (with the “waiting” cursor) until the page has completed.
Consequently, any output or error codes from the command cannot be shown on the page.
Instead, you will have to write your software so that:
shell_exec("cmd &")
or similar.
u
Your command executes asynchronously, using
u
You can update the error or output status through Ajax.
u
You can retrieve error states through a secondary command, issued after an
asynchronously command invocation.
None of these are unsolved problems, but it is an extra layer of complexity for those wanting to write their own
home automation web applications.
Search WWH ::
Custom Search