Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 617495 - /etc/csh.login modified umask after profiled.d scripts are sourced which is inconsistent with bashrc
/etc/csh.login modified umask after profiled.d scripts are sourced which is i...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: setup (Show other bugs)
5.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ondrej Vasik
qe-baseos-daemons
:
Depends On:
Blocks: 668957
  Show dependency treegraph
 
Reported: 2010-07-23 05:14 EDT by Vishal Gaikwad
Modified: 2012-02-21 00:39 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-21 00:39:09 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 Vishal Gaikwad 2010-07-23 05:14:38 EDT
Description of problem:
A change to the setup rpm added some logic to /etc/csh.login in an attempt to be more consistent with bash login shells. One thing is added was the setting of umask, however unlike /etc/bashrc, the csh.login script is adding the logic at the end of the script after the /etc/profile.d scripts have been sourced.

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


How reproducible:
Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:
The setting of umask in /etc/csh.login happens after the /etc/profile.d scripts are sourced

Expected results:
The setting of umask in /etc/csh.login should not happen at the end of the script.

Additional info:
What this does is override any potential changes a sysadmin may have implemented to umask in /etc/profile.d.

Prior to RHEL 5.4, you could affect the umask in a csh by adding a script to /etc/profile.d. Now that is not possible.
Comment 2 Ondrej Vasik 2010-07-23 05:33:25 EDT
In fact it is not unlike with bash ... it is now consistent with bash - in bash is umask set in /etc/bashrc - which is sourced after /etc/profile - so it also overrides umask settings from profile.d scripts for login shell (bash -l) ... For consistency reasons it was done the same way in tcsh ( tcsh non-login shell still could be affected by /etc/profile.d/ umask setting scripts). The sequence of tcsh is different from bash - csh.cshrc is sourced first, csh.login second ... 

Current situation in RHEL-5:
bash: umask affected by profile.d .sh scripts
bash -l: umask not affected by profile.d .sh scripts
tcsh: umask affected by profile.d .csh scripts
tcsh -l: umask not affected by profile.d .csh scripts

RHEL-5 before the change and RHEL-6 atm:
bash: umask affected by profile.d .sh scripts
bash -l: umask not affected by profile.d .sh scripts
tcsh: umask affected by profile.d .csh scripts
tcsh -l: umask affected by profile.d .csh scripts

Anyway - it would be better to have even the bash login shell affected by profile.d scripts ... and to revert the change in tcsh ...
Comment 8 Yves Dorfsman 2011-04-29 12:16:58 EDT
> it is now consistent with bash - in bash is umask set in /etc/bashrc - which
> is sourced after /etc/profile - so it also overrides umask settings
> from profile.d scripts for login shell

BUT, on RHEL 5, "umask" is used at the begining of /etc/bashrc, while files from /etc/profile.d are sourced at the end.

With bash, on RHEL 5, you can set a particular umask in one of the profile.d script, and it does *NOT* get overwritten by bashrc. Unfortunately this is not the case with csh, which means that if we need a particular mask, we now have to modify /etc/csh.login and /etc/csh.cshrc, which goes right against the concept of using profile.d.

This is definitely a bug.
Comment 17 errata-xmlrpc 2012-02-21 00:39:09 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.