- not root
- not root
- SuEXEC
- Depends. 644 for files and 755 for folders are a safeish default.
Don't change ownership of anything to www-data unless you want php to be able to edit the contents of that file/folder
Irrespective of anything else you do: folders need read and execute permissions for the user to find files; files need read permissions for the user to read them. If you get any permissions errors when changing things - you've managed to remove these fundamentally required permissions.
If you are not writing any files via your php application, you can leave files owned by you:you. In this circumstance the world permission (xx4/5) is the one which applies.
If you leave the files as owned by you:you with file permissions of 644 (files) what that would mean is that only you can edit the website files - www-data is not you - so it cannot edit the files.
If you want to restrict access to apache + you and block out all other access chown -R you:www-data *
. With file permissions of 640 and folder permissions of 750 you can edit, www-data can read - because then apache reads the group permission (x4/5x).
Restrict to a minimum the paths you allow apache/php to write to - if there's a tmp dir the application needs to write to - allow it to write to that folder only - and for any writable locations if at all possible make sure it's outside the document root or take steps to ensure this writable path is not web-accessible.
Note that "you" should not be root. Allowing direct ssh access as root is an indicator of other security lapses (such as not disallowing password login), but that's a whole bunch of questions unto itself.
[EDIT]: I misunderstood the question. I will write a more appropriate answer here.
I do not know Tiger Security, but I agree that the user nobody is mean to have NO homedir, NO right over any subdir at all and is mean to really to have NO shell at all (and to do never properly do a 'login').
But the actual settings (in /etc/passwd
) are different for different Linux distros and BSDs and *unix.
I checked using this command :
$ grep nobody /etc/passwd
on RedHat 5.2 (that is the same as a Centos), and I find :
nobody:x:99:99:Nobody:/:/sbin/nologin
so probably '/' this is the standard for RedHat/Centos.
I checked on Ubuntu 10.04 :
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
(and '/nonexistent' does not exist)
and on Mac OSX 10.4 Tiger (that is a BSD derivate) :
nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false
(and '/var/empty' exists and is empty)
My guess is that Tiger Security does not like the standard setting on RedHat/CentOS. You can probably safely ignore this warning or you can edit /etc/passwd
setting nobody
's home to an empty or non-existent directory in order to satisfy the Tiger Security test.
Best Answer
I always run services with a dedicated user. So I would create these users:
You should never run the actual services as root!
Often when installing these applications using your distributions package manager, as part of the installation, a user will be automatically created for each of these services.
I typically use CentOS/RHEL and when I install things like Apache, the user "apache" is created automatically at that point. So too for MySQL, and Nginx.