Bug 199817

Created attachment 132866 [details]
Patch for suggested fix

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

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.

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.

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

(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.

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

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/.

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

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

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.