Bug 1722387

Summary: umask set from etc/profile
Product: [Fedora] Fedora Reporter: Martin Osvald 🛹 <mosvald>
Component: setupAssignee: Pavel Zhukov <pzhukov>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: bfinger, byodlows, marcosfrm, otaylor, ovasik, pknirsch, pzhukov, sbonnevi, tmraz, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-03 09:57:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1807957    
Bug Blocks: 1283670    

Description Martin Osvald 🛹 2019-06-20 08:44:18 UTC
This bug was initially created as a copy of Bug #1283670

I am copying this bug because: 

Such change should get to Fedora first before getting to RHEL.


Hello redhat,

please change the way how you set the umask for users in el6. Currently the umask is set from /etc/profile with this code:

if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 002
else
    umask 022
fi

which overrides the proper way of setting umask via pam. I suggest to kick out this code from etc/profile entirely and use in etc/pam.d/system-auth:

session [default=1 success=ignore] pam_succeed_if.so quiet uid > 199
session optional pam_umask.so umask=0002

instead. For instance, if you put in current state your umask settings to pam, it will get overridden by etc/profile, so adding a:

session [default=1 success=ignore] pam_succeed_if.so quiet uid eq 508
session optional pam_umask.so umask=0007

to system-auth will result into umask 0002 set from etc/profile for user with uid 508.

Theoretically this little improvement will break nothing ...


regards, daniel

Comment 1 Ben Cotton 2019-08-13 16:49:08 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 2 Pavel Zhukov 2020-02-11 15:40:52 UTC
*** Bug 1801569 has been marked as a duplicate of this bug. ***

Comment 3 Ondrej Vasik 2020-02-24 09:51:54 UTC
Adding Tomas Mraz to this bz, as this would require change in pam system-auth.pamd file. Tomas, are you fine with adding the umask snippet there? I agree it is better place to set umask than profile files from setup. Once added there in rawhide, I can remove the snippets from setup profile files in rawhide.

Comment 4 Tomas Mraz 2020-02-24 14:09:31 UTC
Please note that pam_umask is already called from /etc/pam.d/postlogin. We just need to adjust things in /etc/login.defs so the UMASK value is changed to 022. But to be able to do that we need a new shadow-utils which support a new option HOME_MODE in login.defs which needs to be set to 077 so the permissions of the home directories created for new users is not changed from the expected rwx------.

I do not think that the default umask should be 002 for regular users.

Comment 5 Pavel Zhukov 2020-04-03 20:43:57 UTC
Hi Tomas,
Do I understand correctly we're all set for now: 
https://src.fedoraproject.org/rpms/shadow-utils/c/7309a53c2af98c76e438e050f9dafa0d49175b46?branch=master ?

Comment 6 Tomas Mraz 2020-04-06 07:59:19 UTC
Yes, shadow-utils-4.8.1-2.fc33 should have all the necessary changes for pam_umask to apply umask 022 by default.

Comment 7 Marcos Mello 2020-06-16 10:45:39 UTC
(In reply to Tomas Mraz from comment #4)
> 
> I do not think that the default umask should be 002 for regular users.

So this is Fedora/RHEL behaviour since a long time. I am all in for changing it, but let's hope a can of worms will not be open by the change... :-(

Change the thing in Rawhide and let's see.

Comment 8 Marcos Mello 2020-07-05 20:04:35 UTC
shadow-utils-4.8.1-2.fc33 + setup-2.13.7-1.fc33 will change default umask for regular users from 002 to 022, no? Needs documentation somewhere.

Comment 9 Owen Taylor 2022-05-21 00:09:33 UTC
/etc/profile was changed to remove the code to set umask, but similar code was left in /etc/bashrc - so if you have an interactive non-login shell (like the default for gnome-terminal), the umask stayed 0002.

Sent mail to devel.org to see what people think - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CHZSH7UCPPOTTRYI7MYBU2JDN2JFQOJJ/

Comment 10 Zbigniew Jędrzejewski-Szmek 2022-05-22 10:22:21 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=1902166.

Comment 11 Steve Bonneville 2022-11-15 22:19:57 UTC
(In reply to Owen Taylor from comment #9)
> /etc/profile was changed to remove the code to set umask, but similar code
> was left in /etc/bashrc - so if you have an interactive non-login shell
> (like the default for gnome-terminal), the umask stayed 0002.
> 
> Sent mail to devel.org to see what people think -
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> thread/CHZSH7UCPPOTTRYI7MYBU2JDN2JFQOJJ/

We're seeing the same issue in the RHCSA training.  We've received at least one bug report because this breaks User Private Groups settings: https://training-feedback.redhat.com/browse/RH124-744.