Bug 136859 - inconsistent processing of /etc/profile.d/
Summary: inconsistent processing of /etc/profile.d/
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: setup
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-22 19:02 UTC by Sean Dilda
Modified: 2014-03-17 02:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-27 17:55:04 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Fix this bug for FC3 version (568 bytes, patch)
2004-10-27 14:27 UTC, Sean Dilda
no flags Details | Diff

Description Sean Dilda 2004-10-22 19:02:25 UTC
Changing a users shell between tcsh and bash can change when files
under /etc/profile.d/ get processed.  This inconsistency can cause
several headaches for sysadmins.

The case in question is when someone uses ssh to launch a remote
command that isn't a shell script.

As an example, create the following file in your home directory:
[sean@head4 sean]$ cat env.py
#!/usr/bin/python
 
import os
 
print os.environ['G_BROKEN_FILENAMES']

Then ssh in and run it, like this:  'ssh <host> ./env.py'  If your
shell is set to bash, it will traceback and say that os.environ
doesn't have the key 'G_BROKEN_FILENAMES'.  If you shell is set to
tcsh, it'll print out '1'.

The problem seems to come from /etc/bashrc checking $SHLVL before
processing /etc/profile.d/*.sh   Its trying to guess if its a login
shell (and if /etc/profile already processed the files).  However, in
the case I outlined above, it guesses wrong.

Comment 1 Bill Nottingham 2004-10-23 04:15:14 UTC
If you replace /etc/bashrc with the FC3 version, does it behave?

Comment 2 Sean Dilda 2004-10-27 14:27:10 UTC
Created attachment 105840 [details]
Fix this bug for FC3 version

I tried the /etc/bashrc from setup-2.5.35-1.noarch.rpm and the problem was
still there.

However, when I moved the /etc/profile.d/*.sh processing out of the 'if [
"$PS1" ]' it then started working as I'd expect.  I included a patch of the
changes I made to the fc3 version of setup.

Comment 3 Bill Nottingham 2004-10-27 17:55:04 UTC
a) that looks obviously correct
b) that's changing behavior that's been that way for years. Makes me
nervous. :)

Fixed in 2.5.37-1.


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