Hi group,

I am somewhat new to the *nix way of doing things (I used to host my
personal sites with Apache under MS Windows) and need some advice on how
to set up permissions.

The default Apache (2.0.54) installation on FreeBSD (5.4) puts the docroot
at /usr/local/www/, everything owned by user root and group wheel. The
files are world-readable so Apache (who runs as www:www) can read the files.

However, I do not want the files to be world readable because I plan on
using php scripts that have passwords to databases in them. Although I
trust the users on my system not to abuse those, it still doesn't feel
right to have them out there in the open. So I guess the files under
/usr/local/www/ should have no permissions set for 'the world'.

I also want to be able to edit files in the docroot as a normal user
without having to be root, with the possibility of allowing other trusted
users to do the same, so I guess I need to create a group 'webmasters' and
make that group the group-owner of the /usr/local/www/ dir with rw- access.

Lastly, the webserver (user www) obviously needs read access to the files,
but I guess I can't simply make it the owner of the files because that
would be a huge security risk if one of my scripts or perhaps even apache
itself could be exploited by remote attackers.

So that's basically my problem, how do I set the permissions to allow the
above 3 things? I just can't seem to get my head around it, there's gotta
be a way but I can't come up with one...

Any help is greatly appreciated!

[ Post a follow-up to this message ]

On 2005-09-23, Hans Nieser <h.nieser@gmail.com> wrote:
> However, I do not want the files to be world readable

> I also want to be able to edit files in the docroot as a normal user

> I can't simply make it the owner of the files because

Give the webserver's GROUP permission to read the files, your own
user (or a special user created ad hoc) permission to write and
nothing else. The same for directories + execute permissions.

Davide

--
If Bill Gates had a nickel for every time Windows crashed... Oh wait, he
does!
-- From a Slashdot.org post

[ Post a follow-up to this message ]

Hans Nieser wrote:
> However, I do not want the files to be world readable because I plan on
> using php scripts that have passwords to databases in them. Although I
> trust the users on my system not to abuse those, it still doesn't feel
> right to have them out there in the open. So I guess the files under
> /usr/local/www/ should have no permissions set for 'the world'.
>
> I also want to be able to edit files in the docroot as a normal user
> without having to be root, with the possibility of allowing other
> trusted users to do the same, so I guess I need to create a group
> 'webmasters' and make that group the group-owner of the /usr/local/www/
> dir with rw- access.
>
> Lastly, the webserver (user www) obviously needs read access to the
> files, but I guess I can't simply make it the owner of the files because
> that would be a huge security risk if one of my scripts or perhaps even
> apache itself could be exploited by remote attackers.
>
> So that's basically my problem, how do I set the permissions to allow
> the above 3 things? I just can't seem to get my head around it, there's
> gotta be a way but I can't come up with one...

Create the "webmasters" group, add the www user to it along with any
other "trusted" users.

chown -R root.webmasters /usr/local/www

chmod 660 all files - this allows read/write for the owner and the
webmasters group and no access for others. Then members of the group can
edit/save the files.

chmod 770 all directories - this allows read/write/execute for owner and
group. That way you can create files in the directories as well as
browse to them. No access for anyone else.

I tend to handle things like this in a different way, but this may work
for what you need...

Usually, I will use SetEnv in the VirtualHost container for the site to
set database connection details. For instance:

SetEnv SQL_HOST "localhost"
SetEnv SQL_USER "thisuser"
SetEnv SQL_PASS "thepass"
SetEnv SQL_DB   "databasename"

Then with PHP, you can simply access them all as $_SERVER['SQL_HOST'],
etc. Only the values given for the domain the site is running under will
be able to be seen in the script.

chown root.root httpd.conf
chmod 600 httpd.conf

Then only root can read the apache file with the passwords in it (apache
daemon will still read it at start up). Only problem with this is you
need to be root (or use sudo) to edit the file.

Another option is to use some kind of file encrypt software like ioncube
encoder to hide the login details for the database.

--
Justin Koivisto, ZCE - justin@koivi.com
http://koivi.com

[ Post a follow-up to this message ]

Justin Koivisto wrote:
> Create the "webmasters" group, add the www user to it along with any
> other "trusted" users.
>
> chown -R root.webmasters /usr/local/www
>
> chmod 660 all files - this allows read/write for the owner and the
> webmasters group and no access for others. Then members of the group can
> edit/save the files.
>
> chmod 770 all directories - this allows read/write/execute for owner and
> group. That way you can create files in the directories as well as
> browse to them. No access for anyone else.
>
> I tend to handle things like this in a different way, but this may work
> for what you need...
>
> Usually, I will use SetEnv in the VirtualHost container for the site to
> set database connection details. For instance:
>
> SetEnv SQL_HOST "localhost"
> SetEnv SQL_USER "thisuser"
> SetEnv SQL_PASS "thepass"
> SetEnv SQL_DB   "databasename"
>
> Then with PHP, you can simply access them all as $_SERVER['SQL_HOST'],
> etc. Only the values given for the domain the site is running under will
> be able to be seen in the script.
>
> chown root.root httpd.conf
> chmod 600 httpd.conf
>
> Then only root can read the apache file with the passwords in it (apache
> daemon will still read it at start up). Only problem with this is you
> need to be root (or use sudo) to edit the file.
>
> Another option is to use some kind of file encrypt software like ioncube
> encoder to hide the login details for the database.

Thanks to both you and Davide for the quick responses! I think the SetEnv
approach suits my needs best for now, but I will note down both of the
alternative methods suggested by you and Davide just in case 

[ Post a follow-up to this message ]