Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 608987 - umask set in /etc/profile.d is eclipsed by bashrc
umask set in /etc/profile.d is eclipsed by bashrc
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: setup (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Ondrej Vasik
qe-baseos-daemons
:
Depends On:
Blocks: 661681
  Show dependency treegraph
 
Reported: 2010-06-29 02:25 EDT by Roel Gloudemans
Modified: 2012-02-21 00:39 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 661681 (view as bug list)
Environment:
Last Closed: 2012-02-21 00:39:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0198 normal SHIPPED_LIVE setup bug fix and enhancement update 2012-02-20 09:54:05 EST

  None (edit)
Description Roel Gloudemans 2010-06-29 02:25:08 EDT
Description of problem:
All local environment changes should be set using files in /etc/profile.d. However if the umask is set in a script in /etc/profile.d, this umask is eclipsed by a umask setting in /etc/bashrc

Version-Release number of selected component (if applicable):


How reproducible:
Create a script in /etc/profile.d setting the umask. Login and see that the actual umask does not match the umask that is set.

Steps to Reproduce:
1. echo umask 077 > /etc/profile.d/umask.sh
2. chmod 755 /etc/profile.d/umask.sh
3. login to system
  
Actual results:
After login, the umask is not set to 077


Expected results:
The umask is set to 077
Comment 1 Ondrej Vasik 2010-07-01 04:20:10 EDT
Not always true ... umask is set in the beginning of /etc/bashrc ... and profile.d scripts are run at the end of /etc/bashrc - unless short option for login shell is provided. That seems to be your case (using su - / su -l / bash -l ... whatever what provides login shell option). Simple bash/su without login shell option will source your umask.sh script and set umask as you want ...

Will check why it is done that way...
Comment 3 Robert Marcano 2010-11-11 14:05:20 EST
I can confirm this always happens, the execution process is:

Login shell

1- /etc/profile is executed sourcing profile.d scripts
2- ~/.bash_profile is executed that calls ~/.bashrc and then /etc/bashrc
3- /etc/bashrc is executed and set umask
4- /etc/bashrc do not calls profile.d because it is inside:

    if ! shopt -q login_shell

No Login shell

1- /etc/profile is not loaded
2- ~/.bashrc is executed and set umask
3- /etc/bashrc calls profile.d because it checks it is not a login shell

So profile.d scripts are called before the default umask on /etc/bashrc when it is a login shell and after it when it is not a login shell

This make impossible to set a default umask for a login shell without modifying /etc/bashrc

Should not be the default umask be at the start of the /etc/profile? why change the umask each time a new no login shell is spawn?

I think non login shells must inherit the default umask or any other umask set by the user in .bash_profile without reverting to the default when running /etc/bashrc

NOTE: the exact same steps happens on Fedora releases
Comment 4 Ondrej Vasik 2010-11-11 15:23:33 EST
(In reply to comment #3)
> 
> NOTE: the exact same steps happens on Fedora releases

True only in released Fedora's ... it is already fixed in rawhide since August - http://koji.fedoraproject.org/koji/buildinfo?buildID=189043 ... probably worth of adding into f14, I don't plan update in older Fedoras.
Comment 12 errata-xmlrpc 2012-02-21 00:39:00 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0198.html

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