Docker-nginx: Homogenize www-data between builds

[jrmoserbaltimore]

Currently, the vanilla nginx:latest includes Debian user www-data (33) and group www-data (33).

nginx:alpine includes user xfs (33) and group xfs (33), with no www-data.

It is difficult to use nginx:latest and nginx:alpine interchangeably when www-data does not equate to UID and GID 33. Matching the groups between them would be a good idea.

We may need some discussion with upstream about matching Alpine users to Debian users, although that will have implications. Implications of changing the X Font Server user xfs to another UID and GID should be minimal (XFS isn't even used anymore, is it?).

Short of an upstream resolution, we could add a www-data user and group with duplicate UID and GID. This would be harmless, as nothing is owned by xfs and the X Font Server isn't installed or used in the nginx:alpine build. This resolution is non-ideal, but should provide the ability to switch between nginx:latest and nginx:alpine at will where either will perform the desired job.

[thresheek]

nginx packages on Debian do not use www-data to run, it's 'nginx'.

They're on different UID/GID though:

% docker run -t -i nginx:1.11.7 id nginx
uid=104(nginx) gid=107(nginx) groups=107(nginx)
% docker run -t -i nginx:1.11.7-alpine id nginx
uid=100(nginx) gid=101(nginx) groups=101(nginx),101(nginx)

[jrmoserbaltimore]

On Debian and Ubuntu, uid and gid 33 are www-data. This allows php-fpm, apache, and nginx to all run as the same user/group, although there are also apache and nginx. It's common to use an nginx.conf setting the group to www-data; and even the Debian-based php containers come with the www-data group, although not the nginx group.

As you point out, the nginx group should be made idempotent between all nginx images.

Without this setting, the user needs to run a custom script in the container to create common groups. In workflows using docker-compose pull and docker-compose up -d, this complicates things: locally-derived Docker images need their base images specifically pulled or else they won't rebuild properly.

Mostly I'm just looking for standardization. As I said before, this is hard because the numbers for common groups are different between a few distributions. You can imagine the havoc this plays on NFS environments, too.

[thresheek]

Running php-fpm and nginx as the same user is a bad idea. You should not do that.

[jrmoserbaltimore]

php-fpm runs a pool which runs as a certain user. It will have write access (e.g. upload files) to the Web root directory, and also will create a socket file which is owned by a certain user-group.

Here are your options:

• Run nginx and php-fpm as distinct users, and make certain files and sockets world-readable and world-writable; or
• Run nginx and php-fpm as the user who should have access to the Web data; or
• Run nginx and php-fpm as separate users who are in the same group

In practice, the last two are the ones you should do. This means the same group has to be present in both containers, if you're using containers. When php-fpm is using a socket, it can create a socket only accessible by the user and not the group (mode 0600), but only if nginx and php-fpm run as the same user.

Also, php and apache run as the same user and group in Apache (because it's a child of the apache process), which you are suggesting is a bad idea and should not be done.

In summary: Let's avoid chmod -R 777 html/ and instead run nginx and php-fpm as the correct user.

[mrhyde]

official docker image of php:fpm-alpine sets user www-data with id (82) see

[zyrill]

Why is running "php-fpm and nginx as the same user" a "bad idea", thresheek? The only good solution I found was to set nginx and php-fpm users to the same UID/GID what with SELinux and file permissions else not allowing both to write the same files which is required if you e.g. want to run Nextcloud, Wordpress or the likes.

[thresheek]

I'm not familiar with those applications to comment on how they should operate, but separating the UIDs (and, therefore, their ability to access/write to files) is good, because you don't want one compromised service to propagate failure/compromise to another.

[zyrill]

Ok so you have no clue but you wanted to say something. Thank you. You shouldn't be using Dilbert but his boss as an avatar. Joking aside: you realise webserver and script process manager need to have the same uid and acls, else you will never be able to save a file, right?

[mrhyde]

@thresheek Well, guess what - if you want to nginx to have access to php-fpm socket it must be created with the same user and group, which is in 99% of cases is www-data.

[thresheek]

This will not be done in the base image.