Re: why are files/directories owned by www-data !?
On 26/1/2000 Brian May wrote:
I think you have to trust the webserver not to currupt its
own log files...
the way i understand it the apache parent process (which always runs
as root) is responsible for writing the log files, not the children
running as www-data. and since the apache parent process never
services requests but rather has its children do it, it is far more
difficult to exploit the parent then one of the children. if the
logs are not writable by www-data then an exploited child cannot
tamper with them. it would require root privileges to corrupt the
logs in which case its game over anyway. I see no reason why the bar
for corrupting the logs should be lowered from "gain root" to "gain
www-data"
since my logs were mode 600 root.root on my redhat box and loging
worked perfectly with apache running as nobody.nobody it seems
obvious that there is no justification for logs owned by the
unprivileged www-data user.
Ethan> [eb@plato eb]$ grep www-data /etc/apache/httpd.conf User
Ethan> www-data Group www-data [eb@plato eb]$
On slink, these files are owned by root:root and have 644 permission.
I don't see why www-data should own them either.
I think you misunderstood this one, the config files are root.root
mode 644, i was just showing that apache did indeed run as www-data.
This is where it becomes interesting, and while I disagree with
why it is done that way, I can tell you why it was done that way ;-).
There are 4 conflicting requirements:
1. the web server MUST be able to read stuff stored in /var/www
2. the web server shouldnt have write access to /var/www/*
3. certain data under /var/www might be password protected, and not
open to public.
4. users shouldn't have to log in as root or www-data in order to
change web pages.
here is my suggestion:
/var/www should be owned by root.www-data and be mode 2755, any
subdirectories which a local user becomes responsible for maintaining
should be chowned to that user retaining the www-data group and
setgid permission, this way all files created have the group set to
www-data and any private password protected files only need to be set
to mode 640.
this satisfies 1 since the setgid bit ensures the server is able to
read the files.
this satisfies 2 since the group does not have write permission, and
the owner is either root or the regular user responsible for
maintaining given part of the site.
this satisfies 3 since the group is still able to read it and the
setgid bit allows the group to always be set to www-data not granting
any user privileges to that group.
this satisfies 4 (which is currently not satisfied at all) since any
page that a user is responsible for is owned by that user. the only
thing this does not satisfy is the situation where multiple users
need to maintain a given section, this can be solved in two ways at
the local site: 1) if there will be no private passworded pages the
group may be reset and all files be made world readable. or 2) a
shared user may be used and all users who share a given section given
sudo privileges to it.
However, Linux currently only allows one group per file, so
achieving all of these goals at once is impossible. I think the
apache maintainer has given priority to 1, 3, and 4 over 2.
I have just shown that all 4 can be satisfied with current permission
models, the only place where there is a problem is when you have both
password protected pages and multiple people maintaining the password
protected pages. but that is not solved by the current model anyway
so i consider that a moot point.
Personally, I would give 2 higher priority then 3, but that is
just my opinion.
definitely, I see no reasonable rational for lowering the bar for
defacing the web site from "gain root" to "gain www-data" for which
all apache children servicing requests run as.
Ideally, to fix this, you need two groups, eg:
www-server - readonly access to /var/www/*
www-data - read/write access to /var/www/*
why do you need this? the current www-data group is fine just use the
setgid bit to ensure its set and you need not make any user a member
of it. like i said the only place this falls down is multiple users
AND password protected pages.
Perhaps this will be possible with Ext3 or something.
if Ext3 adds ACL support perhaps, but i was under the impression that
acls are already in the filesystem we just need kernel support.
I propose that /var/lib/dhelp be at the least chowned to root,
/var/www be chowned to root and chmoded to 2755. and all apache logs
be chowned root.adm and chmoded 640. (because passwords can be
revealed if the user accidently enters the passwd as the username)
--
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
Reply to: