Re: [tlug] Permissions on local Apache web testing environment

[Curt Sampson <cjs@example.com>]

On 2009-10-31 20:35 +0900 (Sat), Dave M G wrote:

> Anyway, the thing is, even though I have all the files, now that I have
> placed all my web sites back into their usual spots and set up my
> httpd.conf and hosts files as they were, my sites are behaving very strange.

So now you've learned that there's more information in a backup than
just the filenames and their contents.

And you probably also realize the wisdom of doing restores for practice.
(Using virtual machines can help with this, if your CPU supports KVM.
Unfortunately, Debian-based distros seem to have dropped support for
xen, thus large swathes of machines that used to be able to run virtual
machines can no longer do so. *Sigh*.)

> It seems that the permissions might not have carried over properly,
> because the errors I am getting say things like:
> "failed to open stream: Permission denied..."
> 
> So I tried to find out what the permissions should be, and modify all
> the files....

Right. So if you want to debug this yourself, you need first to make sure
that you understand the basics of how users and permissions work on Unix
systems. Short summary: 

  * every process has a numerical uid and a list of gids;
  * every file is owned by a single uid and gid, and has user, group and
    other access permissions;
  * access uses user perms when uids match, otherwise group perms if the
    gid is in the process' gid list, otherwise other perms;
  * perms are read, write and execute bits, with the obvious meaning for
    files;
  * on directories, r = list, w = create new entries, and x = search
    (i.e., you can access something in an --x dir if you know the name,
    but you can't list the names of things in that dir)

So for your web server, you need two things: apache to be able to
read the website's files, and some user or users to be able to update
the website's files. 

ps will tell you as what user the server process is running (this can
be changed in the apache config file, in many installations), the group
information will be the group list for that uid.

So now you need to figure out from there some reasonable option. If you
don't want the apache user (which is, rememmber running all of your
cgi scripts and so on, which are thus a popular vector for exploiting
systems) to be able to write files, it will either have to access them
via group perms where group can't write, or other perms where other
can read. Remember that if you let other read everything on the site,
anybody on the system can read any of those files which, in the case of
database-type things, may be more access than is granted via the web
interface, which will have its own access control on top of what the
file system does.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com