This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 199817 - Make csh default umask values and profile.d scripts processing more consistent with bash
Make csh default umask values and profile.d scripts processing more consisten...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: setup (Show other bugs)
5.0
All Linux
medium Severity medium
: beta
: ---
Assigned To: Ondrej Vasik
David Lawrence
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-22 12:11 EDT by Alex Yacoub
Modified: 2013-04-12 14:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-14 03:41:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for suggested fix (875 bytes, patch)
2006-07-22 12:11 EDT, Alex Yacoub
no flags Details | Diff

  None (edit)
Description Alex Yacoub 2006-07-22 12:11:13 EDT
Description of problem:

The profile.d is a way for admins to make changes to the global login
environment.  It should also allow the administrator to override any 
actions in the setup package config files (profile, bashrc, csh.login, 
csh.cshrc).

The treatment of the profile.d scripts is different between csh and bash.
In csh, the profile.d scripts are always run last, whereas in bash, they 
are only run last if it's not a login shell.  This means the results are 
different.

If I create a umask.sh and a umask.csh in the profile.d directory, and set
the umask to 007, this only works properly in csh or in a non-login bash
shell.  This is because the profile.d scripts aren't called last in the login
bash shell case.

The fix is simple.  bashrc is always read, and it sometimes runs the 
profile.d scripts.  If, instead, /etc/profile didn't run the scripts and bashrc
always did, the umask would be changed last and would be properly set.

The other possibility is to change the csh scripts to act like the bash
scripts.  Then at least there would be consistency.  However, I feel that 
as sysadmins, we should be given the opportunity to change the umask 
if we have to, without changing the setup rpm.

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

How reproducible: Always

Steps to Reproduce:
1.Create a umask.sh file and a umask.csh file in /etc/profile.d and put "umask 007" in each
2.Run bash, bash -l, csh, and csh -l and run umask from each
  
Actual results:
bash: 0022
bash -l: 0007
csh: 7
csh -l: 7

Expected results:
bash: 0007
bash -l: 0007
csh: 7
csh -l: 7

Additional info:
I've attached a patch for the fix I suggested.
Comment 1 Alex Yacoub 2006-07-22 12:11:13 EDT
Created attachment 132866 [details]
Patch for suggested fix
Comment 2 Phil Knirsch 2006-07-24 11:30:21 EDT
This would introduce a fairly drastic change in behaviour when and how these
startup scripts are being called during login or opening a new shell.

As we strive to keep our Red Hat Enterprise Linux releases as consistent and
stable as possible i'm sorry but i think we can't do this for Red Hat Enterprise
Linux 4.

And changing the config files installed via rpm isn't wrong at all, so modifying
the /etc/bashrc or /etc/profile file directly for such things is the right thing
to do.

Read ya, Phil
Comment 3 Alex Yacoub 2006-07-25 13:45:38 EDT
I don't understand.

Right now, the profile.d scripts are run anytime bash is started in an interactive
shell.  The only difference I'm suggesting is to make it more consistent between
a login and a non-login shell.  The only use cases that could tell the difference 
are mine (umask changing) and anyone who tries to mess with the prompt from 
profile.d (which also currently isn't possible, but has a workaround in /sysconfig/).

My patch, now that I reread it, is no good, in that it doesn't check for an 
interactive shell.  Otherwise, I don't see this change affecting any users who aren't
trying to do what I am.

I can understand if such a change won't be made in RHEL4, but I think it should
at least be examined for a later version of RHEL.
Comment 4 Eugene Kanter 2007-04-01 19:49:10 EDT
I would like to add more inconsistencies which still exist in RHEL5. It seems
that initially /etc/csh.cshrc and /etc/came from the same source since they have
identicall comments. /etc/bashrc was updated many many years ago to include user
private group changes. At the same time /etc/csh.cshrc has never been updated.

Below is just one example:

/etc/csh.cshrc

# By default, we want this to get set.
# Even for non-interactive, non-login shells.
umask 022

# /etc/bashrc

.....

# By default, we want this to get set.
# Even for non-interactive, non-login shells.
if [ $UID -gt 99 ] && [ "`id -gn`" = "`id -un`" ]; then
        umask 002
else
        umask 022
fi


The reason I started to look at cshrc is that command history management if far
superior compare to bash.
Comment 5 Phil Knirsch 2007-05-23 09:26:02 EDT
FYI, i've just today changed the behaviour of /etc/csh.cshrc and /etc/csh.login
to behave a lot more like the bash counterparts in Fedora Devel. The main
changes are:

1) For non-login shells /etc/profile.d/*.csh won't be loaded anymore (just like
for bash and expected behaviour)
2) Umask is now correctly set just like for bash, meaning, if uid > 99 and the
group and username match the umask will be 002, otherwise it'll be 022, again,
just like for batch.

So those changes will make it guaranteed into the next Red Hat Enterprise Linux
release.

Read ya, Phil
Comment 6 Eugene Kanter 2007-05-23 12:36:08 EDT
(In reply to comment #5)
Phil,
have you included command history support and terminal title bar support to
match ones from bashrc? For example I have to manually add something like

bindkey "^R" i-search-back
set echo_style = both
set histdup = erase
set savehist = (1024 merge)
alias precmd 'echo -n "\033]0;${USER}@${HOSTNAME}:${PWD}"; echo -n "\007"'

The final version would require if statements currently present in system bashrc
for interactive/noninteractive shells, proper "screen" support etc.
Comment 7 Phil Knirsch 2007-05-24 06:44:37 EDT
Good point, will include those as well. Just tested them, tcsh prompt and
everything now looks identical to bash prompt.

Very nice fixes. Thanks.

Read ya, Phil
Comment 8 Buchan Milne 2007-07-10 07:14:34 EDT
IMHO it should be possible to apply standard hardening practices to RHEL without
modifying anything from the setup package.

It may not be a problem in this case, but there are other examples where
applying SAOX-type hardening will prevent 'up2date' from working correctly
('up2date -f' is required since /etc/issue has to be modified, and /etc/issue is
marked as %config, not %config(noreplace)).

Now, for the umask issue, since it is a security-related/compliance issue, it
should be possible to ensure the default umask is set, no matter what the user
has done to their environment (or whether there is no environment by default).

At present, the umask is only set in /etc/bashrc, which is sourced by the
*default* ~/.bashrc. Now, if the user's ~/.bashrc is removed, the umask won't be
set. The 'nobody' user is a case in point (there is a home directory by default
- thus pam_mkhomedir doesn't help us - but it contains no .bashrc)

Moving this block from /etc/bashrc to /etc/profile (before the /etc/profile.d
files are source) would solve all the problems, and additionally make it easy to
deploy a security policy by dropping a few files in place (e.g. shipping them in
a package) rather than doing inline editing etc. etc:

if [ "`id -gn`" = "`id -un`" -a `id -u` -gt 99 ]; then
    umask 002
else
    umask 022
fi

While this *can* be explained away with "just edit /etc/bashrc", this still
isn't the correct file (/etc/profile is IMHO), but allowing the setting of the
umask via scripts in /etc/profile.d would make things a lot more consistent.

Some test cases (with no changes to /etc/bashrc, but a script in /etc/profile.d)
# cat /etc/profile.d/umask.sh
umask
echo "Setting umask to 0077"
umask 0077
umask
# su - nobody -s /bin/bash -c 'umask'
0022
Setting umask to 0077
0077
0077
# su - nobody -s /bin/sh -c 'umask'
0022
Setting umask to 0077
0077
0077
# su - operator -s /bin/bash -c 'umask'
0022
Setting umask to 0077
0077
0022
# su - operator -s /bin/sh -c 'umask'
0022
Setting umask to 0077
0077
0077

The present situation is that a umask policy must be configured *both* by
modifying /etc/bashrc, *and* by a script in /etc/profile.d/.
Comment 9 Phil Knirsch 2008-02-22 11:34:02 EST
Good point as well. But for setups where a "reset" of the umask is wanted for
every shell this might be problematic. Simple example would be build
environments where the host umask might be different from the one you'd like to
have in the buildroots. If the umask setup would be moved to /etc/profile
instead the buildroots would then inherit the umask from the host system instead
of getting the default one for the buildroot.

I'll be doing some tests with it and see if this could cause problems for other
cases, too.

Read ya, Phil
Comment 21 errata-xmlrpc 2009-05-14 03:41:06 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0484.html
Comment 22 Steven Roberts 2009-10-30 17:35:33 EDT
Referring to this portion of the Errata:
* when using the csh or tcsh shell, the user's umask is now set exactly the
same as it is for the bash shell. If a process owned by a user creates a
file, the UID number of the user is 100 or greater, and the username and
group name match, then the umask of the process will be set to "002".
Otherwise, the umask will be set to "022".

This actual gets RHEL 5 back to the behavior of RH7.3 and ES3.  In their csh.csrhc's they would set the umask correctly like RHEL 5 now does.

The change in original RHEL 5 bit us on a system where user scripts expected a 002 umask by default.  glad it has been fixed now.

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