umask for non-root users not as expected

[bijay135]

The default umask for non-root users is generally 0002, 775 for folders and 664 for files in any ubuntu server but it seems to be 0022 in this docker image, I am not sure if this is intended or a issue.

scenario:

I am using this image to setup a stack for magento. I have installed composer as well as cron inside this image. It's non-production enviroment so I didn't seperate them into own containers to accommodate for limited hardware resources.

I am using the www-data group as sticky bit to share permissions betwen host and container. The issue arises with files/folders created by cron, composer, php or any other process has umask of 0022, 755 for folders and 644 for files so the files/folders are not writable in host unless sudo, root user or acl is used.

what I have found:

On default ubuntu installation the umask for non-root user is set by the pam_umask.so module. It normally reads from login.defs which has a entry called USERGROUPS_ENAB which converts umask to 0002 for non-root user which has same same uid and gid.

The module is generally called from /etc/pam.d/common-session , this image seems to be missing the module call in this file as well.

what I have tried:

1. manually adding session optional pam_umask.so at end of /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive , this does seems to load the umask value from login.defs, if I change the value it gets reflected but the non-root user umask due to USERGROUPS_ENAB still does not work.

2. manually adding session optional pam_umask.so at end of /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive as well as adding umask=0002 in www-data /etc/passwd gecos field, this works as desired. I can even load the module in pam.d/cron and cron tasks umask is 0002 now.

3. lastly, for docker exec command which I use to run composer as www-data, pam_umask module seems to make no difference, for this adding umask=0002 in www-data user's home .bashrc does the job.

what I want to know:

1. why the USEGROUPS_ENAB is failing to set 0002 umask for non-root user www-data, I even created totally new user the umask is still 0022 with USERGROUPS_ENAB, adding umask to gecos field works here as well.

2. why is docker exec -it -u www-data $container_name /bin/bash not using pam_umask set value, only .bashrc works for this or if I manually do su www-data -s /bin/bash from root exec pam_umask value is set correctly as well.

Thank you for reading it, I have done my best to make it brief. I am hoping to get some insights on this.

[tianon]

Unfortunately, this is a known limitations of containers as currently implemented; see moby/moby#19189 and opencontainers/runc#1650 -> opencontainers/runc#2527 (so likely "just" needs the option added in Docker 😬).

I guess your best bet is probably something like setting your command to bash -c 'umask 0002 && exec ...:

$ docker run --rm php:8.0-cli php -r 'printf("%04o\n", umask());'
0022
$ docker run --rm php:8.0-cli bash -c 'umask 0002 && exec "$@"' -- php -r 'printf("%04o\n", umask());'
0002

[bijay135]

Thank you for the issue threads links, they were really useful.

I tried lots of things and currently have found a temporary fix for this image both interactive and non-interactive tasks. I will mention the fix below for any future readers. Also, do keep in mind I am only trying to change umask for non-root users.

the temporary fix:

1. add pam_umask module for common-session and common-session-noninteractive
2. add umask=002 in gecos field / .bashrc of respective non-root user, since USERGROUPS_ENAB is not working at the moment this will allow only non-root users to have separate umask.
3. 1 and 2 above will set umask value for both non-interactive tasks like process/cron as well as commands from interactive shell like bash docker exec -it -u www-data php bash
4. since docker exec does not load .bashrc so we need to use a wrapper which loads .bashrc to fix this docker exec -it -u www-data php bash -ic "command", the important part is the -i flag of bash which makes it load the .bashrc

files created from cron / bash and docker exec after using the fixes:

fix from docker side

I am hoping opencontainers/runc#2527 will fix docker exec not loading the .bashrc file / provide means to set umask and maybe even fix USERGROUPS_ENAB so we don't need to add umask value to each non-root user's gecos field / .bashrc

reference Dockerfile and docker-compose.yml file

FROM php:7.4-cli

# Install required packages
RUN apt-get update && apt-get install --no-install-recommends -y \
    sudo \
    cron \
    rsyslog \
    logrotate \
    unzip \
\
# Configure umask module for pam
 && echo "\n# Load pam_umask module\nsession optional pam_umask.so" >> /etc/pam.d/common-session \
 && echo "\n# Load pam_umask module\nsession optional pam_umask.so" >> /etc/pam.d/common-session-noninteractive \
\
# Disable mail for crontab
 && echo "\n# Disable mail\nMAILTO=''" >> /etc/crontab \
\
# Disable kernel logging for rsyslog
 && sed -i '/imklog/s/^/#/' /etc/rsyslog.conf \
\
# Install composer
 && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer --version=1.10.10 \
\
# Configure www-data user
 && chsh -s /bin/bash www-data && chown :www-data /var/www && chmod g+w /var/www \
 && usermod -c "umask=002" www-data && su www-data -c 'echo "umask 002" >> /var/www/.bashrc'

version: '3'

services:
    php:
        build: ./server/php
        image: custom-php:7.4
        container_name: php
        volumes:
            - ./test:/var/www/html/test
            - ./.composer:/var/www/.composer
        init: true
        entrypoint: /bin/bash
        command: -c "rsyslogd && cron && tail -f /var/log/syslog"

[tianon]

Glad you got something figured out for what you need.

I'm going to close since there's not anything for us to fix in the PHP image.

[Mugane]

@bijay135 Sadly this doesn't work on the php:apache docker image, Apache runs as www-data, but the user account doesn't seem to exist:

$ sudo docker exec -it php-apache /bin/bash -c "usermod -c \"umask=002\" www-data && su www-data -c 'echo \"umask 002\" >> /var/www/.bashrc'"
This account is currently not available.

Did you have to do anything else to get this www-data user configured?

[Mugane]

@tianon I would recommend fixing the part where umask is 0022, should be 0002. Seems like this subtle difference has been the source of countless hours of deployment issues over the years...

[tianon]

I think "This account is currently not available." is probably su telling you that the www-data user is not one you can "log in" as, but it's hard to say for sure. The account definitely exists (check /etc/passwd and you'll see it, or getent passwd www-data).

As for the umask, this isn't something we've set explicitly anywhere in this repository or image -- it's being inherited from Docker or other involved software (and it isn't something we can directly "set" on the image anyways -- there's no "UMASK" instruction in a Dockerfile, for example).

$ docker pull php:apache
apache: Pulling from library/php
Digest: sha256:67d471f9ce2d1185f0b30f2d89bed811e206462fb2afb0c835932338506e6a19
Status: Image is up to date for php:apache
docker.io/library/php:apache
$ docker run --rm php:apache getent passwd www-data
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
$ docker run --rm php:apache grep www-data /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
$ docker run --rm --user www-data php:apache id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

[bijay135]

@bijay135 Sadly this doesn't work on the php:apache docker image, Apache runs as www-data, but the user account doesn't seem to exist:

$ sudo docker exec -it php-apache /bin/bash -c "usermod -c \"umask=002\" www-data && su www-data -c 'echo \"umask 002\" >> /var/www/.bashrc'"
This account is currently not available.

Did you have to do anything else to get this www-data user configured?

Can't believe this is still a issue after all these years. For your question, try running all commands as below. I pulled php:apache image and tested it, works fine.

# Configure www-data user
 && chsh -s /bin/bash www-data && chown :www-data /var/www && chmod g+w /var/www \
 && usermod -c "umask=002" www-data && su www-data -c 'echo "umask 002" >> /var/www/.bashrc'

[Mugane]

To conclude www-data is definitely a user but not a log-innable user. I was wrong about the umask, it is indeed not a php image issue but the "default" on Ubuntu (0022). I was able to get the umask changed to 0002 for Apache which requires modifying the /etc/apache2/apache2.conf file and a hard server restart. It may not be the only way, I did not have a chance to try @bijay135's solution above. I wonder if that method persists across reboots?

[bijay135]

To conclude www-data is definitely a user but not a log-innable user. I was wrong about the umask, it is indeed not a php image issue but the "default" on Ubuntu (0022). I was able to get the umask changed to 0002 for Apache which requires modifying the /etc/apache2/apache2.conf file and a hard server restart. It may not be the only way, I did not have a chance to try @bijay135's solution above. I wonder if that method persists across reboots?

Yes, it's set once and forget method. Works across reboot. As far as I remember the chsh -s /bin/bash $user makes ww-data login-able. By default no shell is assigned to it.