PHP: get_current_user() vs. exec('whoami')

thanks_in_advance picture thanks_in_advance · Feb 16, 2015 · Viewed 17.3k times · Source

Short version of the question:

What's the difference between get_current_user(); and exec('whoami'); ?

Long version of the question:

  1. I'm on a XAMPP Localhost on a Mac.
  2. I'm using Apache, building a PHP based website in a folder (let's call it folderxyz) within the htdocs folder (var/www in some flavors of Linux+Apache).
  3. I was playing around with a database connection, testing out PDO::ERRMODE_EXCEPTION described here: Link

And I got this error:

file_put_contents(PDOErrors.txt): failed to open stream: Permission denied...

So I did some sleuthing around and it seems that to fix this I need to change the CHMOD settings of file PDOErrors.txt to 777.

However, my questions are about something else. During this process I realized that I don't clearly understand the concept of user in Apache, PHP, and MySQL.

  • The PHP manual says that get_current_user() "Gets the name of the owner of the current PHP script" Link
  • The PHP manual says that exec('whoami') returns "the username that owns the running php/httpd process" Link
  • When I use get_current_user(), I get my firstnamelastname, which is my account name on my Mac.
  • When I use exec('whoami'), I get daemon.

So...

  1. What's the relationship between firstnamelastname and daemon ?
  2. What's the relationship between the "the owner of the current PHP script" and "username that owns the running php/httpd process" ?
  3. Who needs permission to write to PDOErrors.txt? Is it firstnamelastname or daemon ?
  4. Who needs permission to write to PDOErrors.txt? Is it Apache or PHP (or both) ?
  5. Does the concept of a unix-like root account factor-in anywhere here ?

Edit: I updated this to reflect that it wasn't the folderxyz that I had to change CHMOD settings for. I had to change the settings for the file PDOErrors.txt


OP here: for future reference, I put up a parallel question for the Linux platform here (with an accompanying intuitive explanation of what's going on): https://stackoverflow.com/questions/31389892/why-is-the-output-www-data-in-one-case-and-root-in-another

Answer

SamT picture SamT · Feb 16, 2015
  1. get_current_user() (should) return the owner of the file, which is firstnamelastname in this case. There have been reported issues that this function is inconsistent between platforms however. As such, I would not trust its output. daemon is the user Apache is running as.
  2. The owner of the PHP script is the user who owns the file itself according to the operating system. You can run ls -la in the directory your scripts are in to find the user and group the file belongs to.
  3. Whichever user you're editing your scripts with needs to be able to write it, so most likely, firstnamelastname (+rw).
  4. For the folder itself, you should have +rx (execute and read) for daemon and for the PHP file, +r (read). On my installation of XAMMP, they've done this by setting everything in htdocs as public readable, thus daemon can read it, but not write to it.
  5. Mac has a root account that typically owns the htdocs or www directory. It fills the role of a traditional unix root user.

Here is some information on the file owners/groups and the process owner:

host:~$ ls -l /Applications/XAMPP/xamppfiles/htdocs
drwxr-xr-x 3 root admin  4096 2015-01-01 00:01 .
drwxr-xr-x 3 root admin  4096 2015-01-01 00:01 ..
-rw-r--r-- 1 firstnamelastname admin   189 2015-01-31 20:45 index.php

host:~$ ps aux | grep httpd | head -n1    
daemon          45204   0.0  0.1  2510176  10328   ??  S    Tue11AM   0:01.38 /Applications/XAMPP/xamppfiles/bin/httpd -k start -E /Applications/XAMPP/xamppfiles/logs/error_log -DSSL -DPHP

If you wanted to make a file writeable by the daemon user, you can create a new folder and name it as the owner with the group admin (so you can use it too), and give it +rwx for the user and group, with +rx for public:

host:~$ cd /Applications/XAMPP/xamppfiles/htdocs
host:htdocs$ mkdir some_dir
host:htdocs$ chmod 775 some_dir