Permissions "problem" using SCP to copy to root owned folder from local

Question

I'm taking some early forays into setting up a basic LAMP box. It's my first time setting up the software I'll use as opposed to just being handed a working environment, so go easy on me :)

I have installed Apache, and the corresponding htdocs folder has permissions of drwxr-xr-x. I can copy from remote to local fine, but when trying to copy a small directory I get permission denied.

I should mention I am logging in using my own admin user account on the box, and of course htdocs is not owned by me.

So I figure, in my naivety that I just need to sudo the command - that didn't work. Okay, next I'll "fix" the permissions to 774 based on what I read on the web. Nope that did not work either. I am thinking "do I need to add write access to the third "user"? That seems a weird one.

Then I read a forum thread where the guy was told that because the folder was root owned, he'd have to scp the files into his home/ dir on the remote host, then sudo cp them to the apache folder.

Seems a longwinded method to me, but before I try and do that, I thought I'd ask here whether that is true, and whether there were any best practices here and whether any of my assumptions were wrong?

Secondly - what is appropriate permissions for htdocs?

I'm still in the early stages and will probably eventually setup some FTP access, but I'd would be good to know.

Answer 1

There are many ways to skin this cat. Here are some for you to consider:

1. The htdocs tree almost certainly doesn't have to be owned by root. What matters is that it be readable by the Apache user. Depending on the *ix system in question, that may be apache, www-data, or something else. The default file mode you give above, drwxr-xr-x (abbreviated 755) is fine for this.

   So, the question is, who should own this tree, and which group should it belong to. This may be enough:

   $ sudo chown -R dan.apache /var/www
   

   This says user dan owns /var/www and everything under it (-R, recursive) and that group apache has some permissions to it, too. If httpd is running as group apache, it probably gets enough permission to read files in the tree and change directories within it, sufficient for most sites.

2. Another way is to go with whatever permissions you have and simply tell scp to impersonate the owner of the /var/www/ tree:

   mybox$ scp ~/site-mirror/index.html [email protected]:/var/www/htdocs
   

   That copies the local copy of the root index.html file to the appropriate location on example.com, logging in as user www. You can use whatever user name and host name you need here. You just need the ability to login as the /var/www/ tree owner's user remotely. If you can't do that, consider going with option #1, at least to get things set up in a way that does allow you to scp files directly.

   If you set up pre-shared keys for SSH, you won't even have to give a password.

   Instead of scp, I recommend you use rsync for web site development:

   mybox$ rsync -ave ssh --delete ~/site-mirror [email protected]:/var/www/htdocs
   

   This mirrors the contents of ~/site-mirror on mybox (your local work machine) into /var/www/htdocs on example.com, logging in as user www. The advantage of using rsync over raw scp is that you don't have to copy and re-copy files that haven't changed. The Rsync algorithm computes the changes and sends only that.

Answer 2

At a glance, your problem most likely is in the 774 permission setting; you've basically set the directory to be readable, writeable and executable for its owner and group, and readable but not executable for others.

In other words, people not the owner or group can't cd into the directory or access files inside it.

I recommend you do some reading up on file permissions in your spare time; for now try setting the permissions to 755 and see if that fixes the problem.

Extra credit: Look into rsync and scponly... And bear in mind that the user for this only needs to be able to read from the source, but has to have write access to the destination.