Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the context of a larger effort, I've run across a particular issue that is baffling me.

On Mac OS X 10.6.7, using the system provided Apache and PHP, I have created a simple HelloWorld.php script that, no surprise, just prints Hello, World! and nothing else.

Works fine if I execute it as php helloworld.php.

However, if I:

sudo su
su _www php helloworld.php

It emits nothing; php returns pretty much immediately with no signs of execution.

Where have I gone off the rails (and, more importantly, what diagnostic information should I be gathering to help deduce the issue)?

No dice.

 bash-3.2$ls -alF foo.php
-rw-r--r--  1 _www  _www  37 Apr  4 21:08 foo.php
bash-3.2$ ls -dalF .
drwxr-xr-x  56 _www  _www  1904 Apr  4 21:08 ./
bash-3.2$ whoami
bash-3.2$ php foo.php
Hello, World!
 bash-3.2$ sudo sh
sh-3.2# php foo.php
Hello, World!
 sh-3.2# su _www php foo.php

If I copy foo.php to my Webserver's documents root, it works. As it does in my user's docroot; it executes via the webserver just fine, regardless of location.

Even su _www php -v fails to spew anything. Something fishy here.

Derp. The _www user is just busted; no shell. Screws up even the simplest of commands when attempted from the shell.

share|improve this question
Are you able to run this script through the webserver? e.g. works? – Stefan Lasiewski Apr 5 '11 at 5:36

This is very similar to my question "Run cgi-script on commandline as user www?" (FreeBSD).

Here's the problem: The user '_www' has a shell set to /usr/bin/false. According to the manpage "The false utility always exits with a nonzero exit code." su _www will always fail, by design.

This is done for security reasons. If anyone were able to successfully run a remote exploit against _www, which the account which is used to run your web applications, then they will encounter a shell which immediately exits. If this shell were left to be something like /bin/sh, then the _www user would be able to run many commands on the commandline, and that would be bad for security. So therefore, it is set to /usr/bin/false to limit the damage caused by any compromises on your webserver. It is unwise to disable this.

However, setting the _www shell to /usr/bin/false also means that the user '_www' is unable to execute commands on the commandline. Even a simple command like whoami will fail:

# su _www whoami
# echo $?

The solution is too use sudo, not su. This simple example shows that I can now execute simple commands, as user '_www':

# sudo -u _www id
uid=70(_www) gid=70(_www) groups=70(_www)

You will also need to make sure that the user _www is able to read the file. But if you are able to execute this file using Apache webserver, then the permissions are already correct.

share|improve this answer

the first thing to look at is the permissions on the file. In general, web files should be owned by the Apache user.

try chown _www:_www helloworld.php

then try running php as the _www user.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.