/etc/profile is owned by setup, so I am changing the component.  In my opinion, such a change in RHEL is nearly impossible.  Note there is a similar bug against Fedora, which also refers to the code in question: bug #1176589

What is the actual motivation behind this request?

Hello Kamil,

actual motivation is to set some custom umasks per-users/groups using pam, not using theirs $HOME/.profile or other shellrc files .. I commented out an etc/profile umask and put at the and of etc/pam.d/system-auth following lines:

session [default=1 success=ignore] pam_succeed_if.so quiet uid > 199
session optional pam_umask.so umask=0002
session [default=1 success=ignore] pam_succeed_if.so quiet uid eq 508
session optional pam_umask.so umask=0007
session [default=1 success=ignore] pam_succeed_if.so quiet user ingroup not-users
session optional pam_umask.so umask=0027

where lines:

1-2) emulate previous /etc/profile umask settings
3-4) set specified umask for user with uid 508
5-6) set specified umask for members of group "not-users"

Without modifying etc/profile this couldn't be accomplished by using pam because umask from etc/profile will simply override pam umask-related settings.

regards, daniel

If you change /etc/pam.d/system-auth, why can't you change also /etc/profile?

The file is marked %config(noreplace) in RPM meta-data, so your changes will not be overwritten in case the package is updated.  Changing the default behavior is simply not what customers expect from an update of RHEL.

(In reply to Kamil Dudka from comment #4)
> If you change /etc/pam.d/system-auth, why can't you change also /etc/profile?
> 
> The file is marked %config(noreplace) in RPM meta-data, so your changes will
> not be overwritten in case the package is updated.  Changing the default
> behavior is simply not what customers expect from an update of RHEL.

I'm just pointing out (from my POV) very bad default which affects 1:1 also el7 and which requires a change.

Okay, I'm changing the release/version in the header of bugreport to el7. Please consider carefully this proposal. This change appears that will not break anything but rather *fix* a real issue - that umask from etc/profile involuntary overrides umask set using a proper/sane/good-practise method using pam.

regards, daniel

ps. I am not permitted to change a product says bugzilla to me ... Can you please do it for me, eg change el6 -> el7 and version 6.8 -> 7.3

Moved to RHEL-7 ... although I fail to see a strong enough reason for changing the default configuration in RHEL-7 either.

Agreed with Kamil, I see it as wontfix for any released RHEL - even smaller changes in behaviour were reported as regressions in the past. This is relatively big change in behaviour - considering number of scripts existing around. However, this is another ++ for changing this at least in Fedora Rawhide. I'll close it wontfix, unless there is some proof given in this bugzilla saying "this can't break any user script".

Hello,

I've found (within solving bug 1300700) that umask is additionally set from /etc/bashrc too ..

according to bug 1300700 I'd consider it as a final proof, that umask/pam defaults in el should be indeed redesigned ...


regards, daniel

I am a new maintainer of setup package and got to this when going through the existing BZs.

I can see that it was decided this won't get fixed in RHEL6, then RHEL7 and that maybe it could get to RHEL8 if it got to Fedora first, but there wasn't created a BZ for Fedora to push it further.

I am going to clone this BZ for Fedora Rawhide to get it there and change the product for this BZ from RHEL7 to RHEL8 so it doesn't get forgotten as it would happen if we simply closed it as WONTFIX.

Hello Martin ...

thanks, please reconsider redesigning this subsystem. This is just 90's way to set umask like this - utterly painful and backwards. Ofc it works, but well, it just hurts ..

regards, dan

Hello,
This bug was reviewed by  by the sub-system, taking into account the kind of the component, and its use cases. It was not considered as a priority for the next release, so it's being closed now as WONTFIX. Feel free to re-open the bug if there is a business reason to deliver a fix for this issue, and contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:
https://access.redhat.com
This issue will be tracked in Fedora in https://bugzilla.redhat.com/show_bug.cgi?id=1801569