Description of problem: I have noticed that default umask has changed in a gnome session in 0002. I guess this beaviour has changed in the last month (ie: in February). files are created 664 instead of 644 as expected. all users are affected. a standard terminal session uses the default 0022 umask which is set system-wide. Version-Release number of selected component (if applicable): How reproducible: open a terminal in gnome-shell and issue umask command umask is set to 0002 switch to a console terminal and login umask is - as expected - 0022 Steps to Reproduce: 1. 2. 3. Actual results: wrong umask 0002 in gnome-shell Expected results: correct system-wide umask 0022 in gnome-shell Additional info:
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 ***