Bug 614694 - ksh users can't see output from scripts in /etc/profile.d/
ksh users can't see output from scripts in /etc/profile.d/
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: setup (Show other bugs)
4.8
All Linux
high Severity high
: rc
: ---
Assigned To: Ondrej Vasik
qe-baseos-daemons
: Patch, ZStream
Depends On:
Blocks: 616116 616117 616418
  Show dependency treegraph
 
Reported: 2010-07-14 21:52 EDT by Bryan Mason
Modified: 2012-06-14 16:55 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When logging in to an interactive login shell, the contents of the /etc/profile script are executed in order to set up an initial environment. Messages which should have been displayed to the user upon logging in to the Korn shell (ksh) were suppressed due to an internal test to determine whether the shell is a login shell that relied upon the value of the PS1 environment variable having already been set before /etc/profile was executed. However, this environment variable is set in the Korn shell only after /etc/profile is executed, which led to messages never being displayed to Korn shell users. This update provides an alternative test that does not rely on the PS1 variable being set before /etc/profile execution, with the result that messages are properly displayed to users of the Korn shell upon login.
Story Points: ---
Clone Of:
: 616116 (view as bug list)
Environment:
Last Closed: 2012-06-14 16:55:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch. (411 bytes, patch)
2010-09-01 13:28 EDT, Quentin Barnes
no flags Details | Diff

  None (edit)
Description Bryan Mason 2010-07-14 21:52:55 EDT
Description of problem:

    /etc/profile has the following code:

        for i in /etc/profile.d/*.sh ; do
            if [ -r "$i" ]; then
                if [ "$PS1" ]; then
                    . $i
                else
                    . $i >/dev/null 2>&1
                fi
            fi
        done

    However, ksh doesn't set the value of PS1 until _after_
    /etc/profile has been executed, so _all_ messages are suppressed
    for users who have ksh as their login shell.  As a result, scripts
    in /etc/profile.d that _want_ to display information to the
    console can't if the user has ksh as their login shell.

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

    ksh-20091224-1.el4.u2-i386

How reproducible:

    100%

Steps to Reproduce:

    1) Add the following code to /etc/profile.d/hi.sh
    
           echo "Hello ${USER}!"

    2) Log in as a user who's login shell is /bin/ksh.
  
Actual results:

    No message is displayed.

Expected results:

    Hello message should be displayed.
Comment 13 Douglas Silas 2010-07-26 10:36:46 EDT
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
When logging in to an interactive login shell, the contents of the /etc/profile script are executed in order to set up an initial environment. Messages which should have been displayed to the user upon logging in to the Korn shell (ksh) were suppressed due to an internal test to determine whether the shell is a login shell that relied upon the value of the PS1 environment variable having already been set before /etc/profile was executed. However, this environment variable is set in the Korn shell only after /etc/profile is executed, which led to messages never being displayed to Korn shell users. This update provides an alternative test that does not rely on the PS1 variable being set before /etc/profile execution, with the result that messages are properly displayed to users of the Korn shell upon login.
Comment 15 Quentin Barnes 2010-09-01 13:27:45 EDT
The recommended way to check for interactivity of the shell is to test $- for the "i" flag.

I attached a patch that works with all the Bourne-based shells I could check: ash, bsh, ksh, pdksh, sh, and bash.  I think that's the entire list that's included with a RHEL distribution.  (Did I miss any?)  It works fine with all of those.  I tested the patch on RHEL4 and RHEL6b2.  However, I didn't have a machine that had non-RHEL Bourne-based shells such as the original Bourne shell.  For the test to work, the ksh88 (ksh86?) "$-" variable has to be set and the "%%" operator has to be available.

I also noticed another bug and fixed it as well.  The "$i" variable should be double quoted.  If the file in /etc/profile.d has a shell metacharacter (e.g.: "hi there.sh"), it will needlessly fail.  The double quotes fix that.
Comment 16 Quentin Barnes 2010-09-01 13:28:48 EDT
Created attachment 442453 [details]
Proposed patch.
Comment 17 Ondrej Vasik 2010-09-01 14:42:34 EDT
Thanks for proposal, similar but different approach was already used in Fedora Rawhide to fix the issue - see https://fedorahosted.org/setup/changeset?old_path=profile&old=3b679b0f62a4a256db5fe66367ce85fe9baad90b&new_path=profile&new=3b679b0f62a4a256db5fe66367ce85fe9baad90b . It should handle the issue as well.

You are right about the missing doublequoting of the sourced file, good catch - thanks.

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