This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1283670 - umask set from etc/profile
umask set from etc/profile
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: setup (Show other bugs)
7.3
All Linux
unspecified Severity medium
: alpha
: 7.3
Assigned To: Ondrej Vasik
qe-baseos-daemons
:
Depends On: 1176589
Blocks: 1298243 1420851
  Show dependency treegraph
 
Reported: 2015-11-19 09:31 EST by dpecka
Modified: 2017-08-03 03:30 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dpecka 2015-11-19 09:31:55 EST
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 2 Kamil Dudka 2015-11-19 09:49:40 EST
/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?
Comment 3 dpecka 2015-11-19 10:03:56 EST
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
Comment 4 Kamil Dudka 2015-11-19 10:25:45 EST
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.
Comment 5 dpecka 2015-11-19 10:49:54 EST
(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
Comment 6 Kamil Dudka 2015-11-19 11:15:47 EST
Moved to RHEL-7 ... although I fail to see a strong enough reason for changing the default configuration in RHEL-7 either.
Comment 8 Ondrej Vasik 2015-11-19 15:20:59 EST
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".
Comment 9 dpecka 2016-01-21 08:58:01 EST
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

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