Bug 1283670
| Summary: | umask set from etc/profile | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | dpecka |
| Component: | setup | Assignee: | Pavel Zhukov <pzhukov> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.1 | CC: | byodlows, fkrska, jscotka, kdudka, ovasik, pzhukov, tmraz |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-02-11 09:02:54 UTC | Type: | Bug |
| 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: | 1176589, 1722387 | ||
| Bug Blocks: | 1298243, 1420851 | ||
/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 |
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