[ale] Multi-user web server permissions

[scott mcbrien]

On Fri, May 1, 2009 at 11:02 AM, Brian Pitts <brian at polibyte.com> wrote:

> David M Lemcoe Jr. wrote:
> > Hello hello.
> >
> > I currently have a server with about 15 people that have domains on
> > it. When playing around in SSH, I noticed that if I ssh as a user that
> > was not in his own directory, I could change, edit, and view his files.
> >
> > What permissions do I need to set in order for other users not to be
> > able to access others' files, but let Apache access them.
> >
> > It would make sense to first chown the directory, put all the web
> > server users in a group, and chmod everything 707.
>
> Here's a scheme that I think should work. I've never actually seen any
> documentation oon how to accomplish this, so I'd like to hear from
> anyone about problems you foresee or different approaches you would take.
>
> I'm pretending that each user has a home directory where they store
> their files, and that the files apache needs to access are in
> ~/public_html. I'm also mostly pretending that you're starting from a
> blank slate with no existing files, while in reality you'll need to do
> some lot of recursive chmod and chown.
>
> First, set each users primary group to a group where they are the only
> member. It's easy to remember if you make the group name the same as the
> username.
>
> Second, set the users' umasks to 026. This means that newly created
> files will have the permissions 640 and newly created directories will
> have the permissions 751. This means that by default the user can do
> anything to their files and their group can read them. Since the user is
> in a "private" group, only they can access these files. The trailing 1
> on directory permissions lets other users traverse through directories
> but not read their contents.
>
> Third, set each home directory to be owned by its user's username and by
> their primary group. E.G. my home directory would be brian:brian.
>
> Fourth, set their home directory permissions to 750. Now only the user
> can read or write in their home directory.
>
> Fifth, set ~/public_html to be owned by its user's username and by the
> group the webserver is running as. E.G. my ~/public_html directory would
> be brian:www-data.
>
> Sixth, set the ~/public_html directory permissions to 750. Now the web
> server can see inside this directory.
>
> Seventh, set the setgid permission on ~/public_html. This means that
> files created inside the directory will inherit its group owner instead
> of the user's primary group. E.G. instead of being owned by brian:brian
> files in my public_html would be owned by brian:www-data. Now the web
> server can read the files it needs to serve.
>
> I think this does exactly what you asked for.
>
> What if you need several users to be able to edit the same set of files
> served by Apache? One approach is to change the umask to 002, put the
> users in a group together, set that group as the owner of the directory
> where the files to be edited reside, and enable setgid on it. This
> requires relaxing your restriction that files can't be world-readable,
> which may or may not be reasonable (e.g. it's fine if you're serving
> static content and apache wasn't doing any authentication, it's less
> fine if you have cgi programs with database passwords in them).
>
> --
> All the best,
> Brian Pitts



If you put the web content outside the user's home, or set the user's home
to a directory not /home, ie: /var/www/hosted/* , you can set a default acl
for the apache user to get rx perms on any file/directory created therein.
 aka  setfacl -m d:u:apache:rx /var/www/hosted

Then you can either set the perms on the directories within hosted to be 700
so just the user has access to place/remove content files.  If several users
who belong to the same group are going to be manipulating content, set the
shared group as their directory owner and set the perms to 2770 so that the
group owner propagates.  Because you already added the default acl for the
apache user, as though by magic, the web server still gets access to all
those people's files even though the user-group-other permissions indicate
otherwise.

ACLs, ACLs, ACLs

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20090501/db596e7b/attachment-0001.html