Bug 1722387 - umask set from etc/profile
Summary: umask set from etc/profile
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: setup
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Zhukov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1801569 (view as bug list)
Depends On: 1807957
Blocks: 1283670
TreeView+ depends on / blocked
 
Reported: 2019-06-20 08:44 UTC by Martin Osvald 🛹
Modified: 2024-02-19 15:33 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-03 09:57:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1902166 1 unspecified CLOSED bashrc sets hardcoded umask 2022-11-24 10:30:15 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.