Bug 1940375

I fully confirm this bug, which is a SECURITY ISSUE.

I think that the cause is a regression in systemd :
Its pam_umask module should correctly take into account UMASK in /etc/login.defs, and umask= in the 5th field of /etc/passwd
See https://bugzilla.gnome.org/show_bug.cgi?id=780622

-  On Ubuntu 20.04.2, the current systemd version is 245.4-4ubuntu3.7, and UMASK from /etc/login.defs and /etc/passwd are correctly taken into account.

-  On Fedora 34, the current systemd version is 248.4-1, and the problem is systematic.

If possible, please change the component of this bug to systemd and its description to 'systemd --user should correctly use pam_umask to take into account UMASK in /etc/login.defs, and umask= in the 5th field of /etc/passwd'.

Thank you in advance for a quick fix.

done, let's see what they say, hoping it's not a "not a bug; wont fix; fuck you" response :-)

(In reply to Davide Corrado from comment #2)
> done, let's see what they say, hoping it's not a "not a bug; wont fix; fuck
> you" response :-)

f*ck ... o f*rt U.  ;)

Here is what I did on Fedora 34 to get this work again. I have added a new line to the file "/etc/pam.d/systemd-user": session optional pam_umask.so. Additionally I have changed the entry in "/etc/login.defs" from "UMASK 022" to "UMASK 002", because I want "UMASK 002". Reboot and that's it. I have to mention that I use KDE Plasma.

On Fedora 34, I just tried the workaround proposed by Attila, and rebooted, but it did NOT work for me :

$ grep  -s  -i  '^[^#]*umask'  /etc/pam.d/*  /etc/login.defs  /etc/profile.d/*  /etc/profile  ~/.profile  ~/.bashrc
/etc/pam.d/postlogin:session     optional                   pam_umask.so silent
/etc/pam.d/systemd-user:session  optional pam_umask.so
/etc/login.defs:UMASK           027

$ grep  "^$USER:"  /etc/passwd
urbah:x:1000:1000:Z_URBAH,,,,umask=027:/home/urbah:/bin/bash

$ ps -fC '(sd-pam)'
UID          PID    PPID  C STIME TTY          TIME CMD
urbah       2634    2632  0 04:50 ?        00:00:00 (sd-pam)

$ umask
0002

Inside Fedora 34 :
- Has https://bugzilla.redhat.com/show_bug.cgi?id=1722387 correctly been implemented ?
- Has https://github.com/systemd/systemd/pull/15318 been applied ?

Thank you in advance for your work.

(In reply to Etienne URBAH from comment #5)
> On Fedora 34, I just tried the workaround proposed by Attila, and rebooted,
> but it did NOT work for me :
> 
> $ grep  -s  -i  '^[^#]*umask'  /etc/pam.d/*  /etc/login.defs 
> /etc/login.defs:UMASK           027

Hi,

I see umask 027. Are you sure? You want umask 022. Perhaps a typo?

I apologize for accusing the innocent 'systemd' component :

In fact, the problem is in the 'bash' component itself (current version is 5.1.0(1)-release) :

$ for  p  in  $PPID  $$;  do  cat  /proc/$p/cmdline;  echo  -n  '   ';  grep  -i umask  /proc/$p/status;  done
/usr/bin/konsole   Umask:       0027
/bin/bash   Umask:      0002

$ grep  -B 1  -i umask  /etc/bashrc

    # By default, we want umask to get set. This sets it for non-login shell.
--
    if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
       umask 002
    else
       umask 022

So, please change the component of this bug to 'bash' and its description to '/etc/bashrc must NOT force umask, because it is already set correctly by systemd using the pam_umask module'

Workarounds :

If you are sudoer, comment the 4 above lines inside '/etc/bashrc'.

If you are not sudoer, you can add following lines at the end of ~/.bashrc :
UMASK="$(grep  -o  "^$USER:.*,umask=0[0-7]*"  /etc/passwd)"
if  [ "$UMASK" ];  then
  umask  "${UMASK#$USER:*,umask=}"
fi

Etienne, thank you for the investigation.

There might be other bugs, but at least the code in /etc/bashrc seems to be problematic.
It shouldn't set umask in most cases, but there is one very special case where it should:
the kernel invokes PID1 with umask=000, so when running with init=/bin/bash, bash should set the umask.
Thus, please change /etc/bashrc to only touch umask if it is 000, and leave the existing setting otherwise.

`/etc/bashrc` belongs to `setup` package.

*** This bug has been marked as a duplicate of bug 1902166 ***