Correct owner/group/permissions for Apache 2 site files/folders under Mac OS X?

Question

It's hard to find Mac-specific answers to this question on the web, so I'm hoping someone out there can put this one to rest for me? My permissions are screwed up on my sites and I'm not sure how to fix them without just slamming a recursive 777 on everything which is quite obviously incorrect.

Thanks!

Solution 1

This is the most restrictive and safest way I've found, as explained here for hypothetical ~/my/web/root/ directory for your web content:

• For each parent directory leading to your web root (e.g. ~/my, ~/my/web, ~/my/web/root):
  • chmod go-rwx DIR (nobody other than owner can access content)
  • chmod go+x DIR (to allow "users" including _www to "enter" the dir)
• sudo chgrp -R _www ~/my/web/root (all web content is now group _www)
• chmod -R go-rwx ~/my/web/root (nobody other than owner can access web content)
• chmod -R g+rx ~/my/web/root (all web content is now readable/executable/enterable by _www)

All other solutions leave files open to other local users (who are part of the "staff" group as well as obviously being in the "o"/others group). These users may then freely browse and access DB configurations, source code, or other sensitive details in your web config files and scripts if such are part of your content. If this is not an issue for you, then by all means go with one of the simpler solutions.

Solution 2

If you really don't like the Terminal here is the GUI way to do dkamins is telling you :

1) Go to your user home directory (ludo would be mine) and from the File menu choose Get Info cmdI in the inspector :

2) By alt/option clicking on the [+] sign add the _www group and set it's permission to read-only :

• Thus consider (good practice) not storing personnal information at the root of your user home folder (& hard disk) !
• You may skip this step if the **everyone** group has **read-only** permission but since AirDrop the **/Public/Drop Box** folder is mostly useless...

3) Show the Get Info inspector of your user Sites folder and reproduce step 2 then from the gear action sub-menu choose Apply to enclosed Items... :

Voilà 3 steps and the GUI only way...

Solution 3

I know this is an old post, but for anyone upgrading to Mountain Lion (10.8) and experiencing similar issues, adding FollowSymLinks to your {username}.conf file (in /etc/apache2/users/) did the trick for me. So the file looks like this:

<Directory "/Users/username/Sites/">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride All
  Order allow,deny
  Allow from all
</Directory>

Solution 4

2 month old thread, but better late than never! On 10.6, I have my webserver documents folder set to:

owner:root
group:_www
permission:755

_www is the user that runs apache under Mac OS X. I then added an ACL to allow full permissions to the Administrators group. That way, I can still make any changes with my admin user without having to authenticate as root. Also, when I want to allow the webserver to write to a folder, I can simply chmod to 775, leaving everyone other than root:_www with only read/execute permissions (excluding any ACLs that I have applied)

Solution 5

On my 10.6 system:

vhosts folder:
 owner:root
 group:wheel
 permissions:755

vhost.conf files:
 owner:root
 group:wheel
 permissions:644

View more solutions

Comments

[Fo.]

Great, thank you Steve, and for the web files themselves? /Library/WebServer/Documents /Library/WebServer/Documents/[file] /Library/WebServer/Documents/[directory]

[dkamins]

You don't need to set the owner to 'root', but it's harmless. You definitely don't need the o+rx perms you have -- that lets any local user browse and read all your web content (including possibly configs with DB passwords, etc.)

[dkamins]

(see my answer to this question below which is a much more complex version of this answer which may be interesting to those more paranoid about security)

[Robert Hui]

That solved my problem perfectly! OSX 10.7.5 on a MBP. I turned on Web Sharing, could hit html pages in /Users/[name]/Sites/, but couldn't grab JS/CSS from subdirectories in the same folder. It returned 403 forbidden errors. The 4th instruction, "sudo chgrp -R _www ~/my/web/root" did the trick.

[bhavinb]

I had to give read access in addition to the x flag with chmod go+rx DIR at the /Users/username directory level before ls stopped throwing permission error. Wonder why?

[Elliot]

For Step 3, I had to use chmod go+rx DIR in order to be able to ls inside DIR myself.

[mike]

Not to bump an old thread, but does running chgrp to _www on web root mess up write permissions if I'm creating or editing my docs?

[dkamins]

@mike, All the files and directories will still be owned by you (the user) and still be writeable. The chgrp only allows the "_www" group to read the files.

[mike]

^ answering my own question: no. new folders/directories inherit permissions.

[ktamlyn]

I created a user "git" which I don't use, and that was all there was available in that directory to edit (git.conf). Once I updated the file as described above for user git - the directory I set up was served correctly by apache. This doesn't make sense to me because my user git has nothing to do with the created directories, or apache.

[Brad]

you should warn users not to apply this to folders under /Users. i'm sure that's obvious to most, but not to me, a n00b to OS X. this totally messed up my permissions.

[Jpsy]

For systems that expect the website scripts to create their own folders and write their own files within webroot (like many CMS do) I had to give write permissions to the _www group. So the last step becomes chmod -R g+rwx ~/my/web/root. Any objections or a better way to do this @dkamins ?

[dkamins]

@Jpsy That should work fine if your app needs to write to itself. It introduces other potential security issues if other code is running also as _www (and might maliciously alter the CMS code), so just be careful. If you can restrict writeable (g+w) to a deeper subdirectory, that's better yet.

[dkamins]

This is a few years old now, time marches on, and OS X likes to change how its default Apache server works from time to time. So while this solution still works, I would at this point strongly recommend the alternate solution of creating local VMs to test your apps on instead of using OS X itself. See: vagrantup.com

[Ola]

good job @dkamins. step 4 was only what I needed: sudo chgrp -R _www ~/my/web/root Then I did a chmod -R 775 ~/my/web/root/particluar_site_folder/log_folder because I needed the log directory to be writable by the web server.

[racl101]

Here's a great guide which shows how to only change the ownership and permissions to the _www user for WordPress specific installs (in case one is apprehensive about modifying the entire web root). It sort of relates to this problem on a smaller scale. coolestguidesontheplanet.com/…

[CoolArts]

This is the best way by far, alt+click shows the properly _www user

[llange]

This is true if you have guest file sharing activated or a malicious php script installed… Make sure there's only the Public and Sites folder which is "readable" by everyone. Step 3 applies only to the "Sites" folder… Thus normally others folders shouldn't be altered…

[DarkNeuron]

This shouldn't be needed. _www is in the everyone group.

[landed]

In terminal how do we see what for example wordpress got installed with (regarding its own file permissions) as I want wordpress to be able to write its own media uploads...

[llange]

PS it seems that with Sierry the Alt trick doesn't work anymore (I still have to check if there's some GUI option to enable but I don't think so according to recent Apple policy/practice).

[AamirR]

alt/opt + [+] still works for me in High Sierra 10.13.5, thanks

[llange]

Was a bug with one of Sierra builds…