Actually, I said /etc, but thats a minor quibble. Template files are
configuration files. Configuration files belong in /etc. Where '/'
is really located is the more interesting question.
There are 3 primary web application layouts, and a flexible
application can (and should) support them all. You've got the
single-instance-on-a-single-OS layout. You've got the mass vhosting,
or multiple-instances-on-a-single-OS layout. And you've got a
no-privilege or per-user layout. Fundamentally the only thing thats
different between these layouts is where the root of their filesystem
is. In mass vhosting scenarious I've used / var/www/<host>, I've used
/home/<host>, you get the idea--and the configuration files for that
instance have always gone in <prefix>/etc/ <application> because thats
where configuration files go, in etc. Individual users hosted off a
single web server really isn't any different from multiple vhosts
hosted off a single web server, except frequently the former could
have more privilege (additional unix accounts) at it disposal than the
latter.
The ownership of configuration files will vary between applications,
but the simple principle to work by is that whomever is responsible
for maintaining the application should have the ability to write to
the files, and applciation process owner needs to be able to read
them.
For example, lets look at two layouts of the same application on a
Debian server.
Given: Application "foo", in a single- instance-on-a-single-OS layout,
where foo needs two configuration files "database.cfg" and
"lookyfeely.cfg". Web server process runs as "www-data:www-data".
The maintainer is "bob:bob". database.cfg has sensitive info in it.
consider:
$ ls -al /etc/foo
total 6
drwxr-xr-x 3 root root 1024 2004- 02-09 15:21 .
drwxr-xr-x 66 root root 4096 2004- 02-09 15:21 ..
-rw-r----- 1 bob www-data 24 2000-05-28 06:59 database.cfg
-rw-r--r-- 1 bob bob 122 2004- 01-05 23:13 lookyfeely.cfg
Thats not a bad solution, the web server process can read
database.cfg, bob can edit both files, and lookyfeely is readable by
everybody, it contains no sensitive information so hiding its contents
from the other system users is unneccesary and www-data needs to be
able to read it anyway. This requires super- user privileges to
configure initially, but thats OK on a single- instance-on-a-single-OS,
thats how it should be.
Now lets look at, moving to a per-user layout.
Given: Application "foo", in a per-user layout, where foo needs two
configuration files "database.cfg" and "lookyfeely.cfg". Web server
process runs as "www-data:www-data". The maintainer is "alice:alice".
database.cfg has sensitive info in it.
consider:
$ ls -alR /home/alice
/home/alice:
total 13
drwxr-xr-x 3 alice alice 1024 2004- 02-09 15:21 .
drwxr-xr-x 6 root root 4096 2004- 02-09 15:21 ..
drwxr-xr-x 6 alice alice 1024 2004- 02-09 15:21 etc
drwxr-xr-x 3 alice alice 1024 2004- 02-09 15:21 public_html
/home/alice/etc:
total 6
drwxr-xr-x 3 alice alice 1024 2004- 02-09 15:21 .
drwxr-xr-x 6 root root 4096 2004- 02-09 15:21 ..
-rw-r--r-- 1 alice alice 24 2000- 05-28 06:59 database.cfg
-rw-r--r-- 1 alice alice 122 2004- 01-05 23:13 lookyfeely.cfg
/home/alice/public_html:
...
Now we run into a problem because any other system user can read
alice's database configuration file, and thats bad if the other system
users aren't trusted. But there isn't let the web server read the
configuration it needs to if alice doesn't have any additional
privileges. This leaves you with a lot of options which I'm not going
to delve deeply into except to say: more groups, setfacl, Apache's
suexec, or any number of other hacks will work around this issue. Its
not the applications job to dictate which method should be chosen, but
if possible it shouldn't stand in the way of any of them.
Back to the meat of original issue, the web server does not ever need
to serve configuration files. Ever. Doing so is adding needless
complexity to a fragile system. So allow me to refute your 3 points
on when its a good idea, because I assert it is never a good idea:
1) The application is, or instances thereof are, ment to be installed by
users with no special privileges.
Then either the application must never store sensitive information,
or the web server must be configured to use a tool like suexec so the
CGI scripts run as that user. Either way, as templates normally don't
contain sensitive information this is moot, and its still not a good
reason to leave them in a publishable directory, the CGI application
can just as easily specify an include path and pull the templates from
a directory in the users control that isn't publishable by the web
server.
2) The overhead for a different solution (e.g. precompiled templates
in a database) isn't worth it.
meh--the filesystem is a database, you wouldn't put data that had nothing
in common into the same table of a RDBMS, why do it in a filesystem?
-or-
meh--the filesystem is a namespace, you wouldn't put methods that had
nothing in common in the same API, why do it in a filesystem?
3) The application is designed to run multiple instances, each
potentially with different templates.
Every instance should have its own configuration directory. The
reality is that when this is the case there's a very good chance that
you're going to need configuration data for other applications
belonging to the instance as well, best plan for it ahead of time.
Edited by Chady -- fixed formatting.
|