Description of problem: Hardcoded umask has been removed from /etc/profile in 102b349c39e196cc1e34e645c9310acdab7afeef but bashrc sets same values for non-login shells. Opening this bug to check if it's still OK or should be changed to use login.defs too to avoid possible regressions
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
There's a related conversation here https://ask.fedoraproject.org/t/default-umask-value/18648 The current configuration does seem pretty arbitrary to me, especially the distinction between login and non-login shells. I note that there's a lot of back-and-forth history in the changelog (see for example #217523). Personal opinion: that shared-login-server filesystem-permissions-based-collaboration use case is a pretty rare one these days, and systems where that's still important can explicitly configure for that if needed. And I also note that the check there for UID > 199 is ... maybe a decade obsolete? Let's just take this out? Less code is better, right? :)
*** Bug 1940375 has been marked as a duplicate of this bug. ***
I'm copying over a comment from the other bug so this doesn't get lost: > please change /etc/bashrc to only touch umask if it is 000, and leave the existing setting otherwise.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
This bug is still present in package setup 2.13.10-1.fc36 Workarounds : If you are sudoer, inside '/etc/bashrc', you can replace 'umask 002' by 'true # umask 002 now managed by pam_umask' 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
Would this be an acceptable solution for the parties involved? https://pagure.io/setup/pull-request/36 https://pagure.io/fork/mosvald/setup/c/206d4afccaec7b20caafa79d6b005ec681e2551b
Works for me. Thanks!
FEDORA-2022-984296572a has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-984296572a
FEDORA-2022-4b663b23a9 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-4b663b23a9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4b663b23a9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-984296572a has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-984296572a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-984296572a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-984296572a has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-4b663b23a9 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.