chown www-data but httpd runs as user daemon

[sourcejedi]

The default httpd.conf sets User daemon. So it's kind of odd to have chown www-data in the Dockerfile. (www-data is the default when you install the apache packages from debian, as opposed to the upstream tarball).

It's not exactly a bug - it works because the directory is readable by any user. However it could cause confusion if you need Apache to have write access somewhere.

Fortunately the PHP+Apache image sets User www-data in httpd.conf. Maybe User www-data (and Group) should be added to the sed command in this Dockerfile, which edits the config file?

[tianon]

Oh hmm, this is an interesting one. I'm not sure how we missed it (sorry!) but I think I'm actually leaning towards swapping www-data for daemon, given that's what upstream provides/uses.

[sourcejedi]

I'd like to re-emphasize the opposite preference :-P.

The name of the user varies between distributions, so there isn't one standard we could suggest changing upstream to use. That said, upstream probably should use apache (like Fedora) to avoid encouraging security problems (more explanation below).

I believe using a well-known name would avoid some confusion. Everyone hits permission errors at some point :). There's a lot of instructions out there that talk about www-data, because Debian is so widely used. We're using a Debian base here, and deb/ubu is also widely used in Docker. (Possible counter: future base change e.g. to Alpine Linux? Maybe that argues for a generic "apache" instead of Debian-derived "www-data").

---

I suspect upstream specifies daemon because they expect that user to exist. However, outside of Docker, no-one does this anymore, it's a terrible idea. You use a specific user to run Apache, you don't run it as the same user as all your other daemons.

[kuborgh-mspindelhirn]

Is there an update on this one? I would love to see a comprehensible user selection.
PHP and nginx images use www-data user with the same ID ( 82 ). So I tend to agree with @tianon

[NicolasWebDev]

Any update on this? I kept looking quite a long time, because I was creating a mod_cache_disk directory, and I could not get it to write successfully.

[rioncarter]

A possible work-around for this issue is to mount an alternate httpd configuration that sets the User www-data directive at launch time using a docker volume pointed to a custom httpd.conf file:

docker run -dit --name my-apache-app -p 8080:80 -v /path/to/modified-httpd.conf:/usr/local/apache2/conf/httpd.conf -v "$PWD":/usr/local/apache2/htdocs/ httpd:2.4

In my testing this works as the www-user is specified in /etc/passwd (has a uid of 33 which matches an ubuntu test system I have).

While this is not an elegant solution, it helps to understand alternate options.

[cdjenkins]

I ran into this issue. I kept using RUN chmod www-data:www-data <file>. It never worked. When I added RUN chmod 755 <file> to the Dockerfile, the index.html page loaded. After running RUN cat <path/to/conf/file> I see that the image uses the daemon as the httpd user and not the assumed www-data. After setting RUN chown daemon:daemon <file>, everything worked. Just my 2 cents.

[gglockner]

This is most likely user error: in your apache configuration file (httpd.conf), fix this issue by writing something like the following:

LoadModule unixd_module modules/mod_unixd.so
# ...
<IfModule unixd_module>
User www-data
Group www-data
</IfModule>

[fzipi]

The problem happens because the default config file has daemon already. Take a look here. When you do the default make install, will just copy that data. Looks like this was changed... in 2005? So I would say this is definitely a bug in the build process, and daemon should be changed to www-data.

One easy fix is use this sed to change also daemon to www-data.