I've used system($cmd) for years with very reliable results until F17 and PHP 5.4.4. The programs execute, ok, but they can't see any files in directories owned by root, regardless of permissions. PHP itself can read root-owned files, but not shell_exec() programs. I run apache as a specific user and when I log in as that user, the commands work fine from the command line, but when they execute from the shell_exec() call, they can't find files the programs are trying to read from.

For example,

$tmplist = `/bin/ls /tmp`;

returns
total 0

However

$tmplist = `/bin/ls /`;

returns a full listing of the root directory.

There are many files in /tmp when I execute "/bin/ls /tmp" from the command line, but they don't show up when ls is executed from PHP. I have tried system(), shell_exec(), backticks, and exec(). All have the same result. Commands execute. "/bin/env" lists the environment variables the shell_exec() runs with, "/bin/whoami" outputs the web server's user name. It's just when the executed program tries to read a file in a directory owned by root, it thinks they don't exist. I first saw this when a program errored with "No such file or directory" when trying to read from a file that I KNEW was there (same command found it from the login shell).

I'm assuming this is a security "feature" of the new PHP or F17, but I can't find anything about it in the Google machine. Sounds like an Selinux thing, but Selinux is disabled. F17 updates applied and everything is current. Anyone know what's causing this?

The results of your testing don't seem to agree with that. (The / directory is root owned, and you said you got a full directory listing.)

Are you logging and/or showing errors? (And what level of error_reporting do you have enabled?) That's where I would start the search for clues.

I was afraid someone would call me on that. I should have said "except the system root directory". As for logged errors, yes, the apache errors log is where I found the original error message from an app that couldn't find the same file that could be found by the same app when run from the command line, logged in as the same non-root user that apache runs as.

Focus on the empty /tmp. That's owned by root and read/writable by all and yet it shows up as empty when "ls /tmp" is executed via shell_exec(). Believe me, I have found a LOT of clues and it took a bunch of log examination and special programming to get this far. You may notice that I just joined LQ, but I've built many linux machines since the early days of RedHat (including two generations of high availability servers running RHEL5 and CentOS 6 at work) and never needed to post before (always found answers from others with similar issues). I've googled this one for a week, now, and no clues, so far. Thanks for the reply, though.

UPDATE: I just tried CGI script (perl) and same problem, so it's apache/system config, not PHP! Still looking...

Well, it turns out that the two root-owned directories I had tried were the ONLY two root-owned directories shell_exec'ed apps can't read (other than those without world read permissions). I wrote myself a CGI script called ls.cgi that gives a detailed listing of the directory passed to it and replaces the directory names with links to itself, letting me browse around the filesystem. I have yet to find a directory other than the two I'm interested in that it can't read: /tmp and /var/tmp. There must be some permission setting that I can't see with the usual ls. Anyone recommend a tool to check/set permissions that would inhibit a CGI script-called app from seeing files that the same app, called from command shell can see?

Found it! Turns out that F16 intruduced the concept of a private /tmp and /var/tmp directory for services that keeps their temp files from being visible to other processes. Makes sense for security, but makes it difficult for services to share files with users and breaks my scripts. It can be disabled, though, which is fine for my home media/web/file server.

Explained under 2.3.3. Services Private /tmp at http://docs.fedoraproject.org/en-US/..._Sysadmin.html

and http://fedoraproject.org/wiki/Featur...icesPrivateTmp

1 members found this post helpful.

Interesting. Thanks for sharing your solution. You're in rare company.