2

Since forever we used to launch user scripts from a different user crontab like this:

00 12 * * 1 su - user2 -c "/home/user2/myscript.sh"

By doing this, the script is launched after the interactive shell loads ~/.bash_profile .

However, recently we've patched Bash to 4.3.27 version, because of the "shellshock" vulnerability, and this is no longer working.

We still have a copy of the old bash so we can test the problem:

[root ~]$ /bin/bash --version
GNU bash, versión 4.3.30(1)-release (x86_64-unknown-linux-gnu)

[root ~]$ /bin/bash.old --version
GNU bash, versión 4.1.2(1)-release (x86_64-redhat-linux-gnu)

[root ~]$ echo "export MYNEWVAR=helo" >> /home/usertest/.bash_profile

[root ~]$ su -s /bin/bash - usertest -c "env | grep MYNEWVAR"
[root ~]$ su -s /bin/bash.old - usertest -c "env | grep MYNEWVAR"
MYNEWVAR=helo

Is this an expected behaviour? or did we miss to enable some features in the configure step compiling bash?

Regards.

Improve this question
1
  • I suspect you missed something in the configuration/compilation phase. You should have been able to find the options that your vendor used to compile the original binary so you could provide those same options.
    – Zoredache
    Nov 7, 2014 at 20:08

1 Answer 1

Reset to default
-1

Updated since demoting vote so please if this corrects the issue as it looks like when I used a Virtual machine and arch please vote so I get the -1 removed please.

If your system uses SUDO see 2nd half below...

For Systems that use SU ONLY:

In some systems it can be aliased so even if you use su it auto uses su - which forces the use of the new user's variables as found in their bashrc

Look at your personal user bash.rc for the mentioned alias below and remove it. That should stop it from trying to use the root user's set variables.

page: https://wiki.archlinux.org/index.php/su
Relevant Bit:

Thus, administrators should generally use su as follows:

$ su -

An identical result is produced by adding the username root:

$ su - root

Likewise, the same can be done for any other user (e.g. for a user named archie):

# su - archie

You may wish to add an alias to ~/.bashrc for this:

alias su="su -"

For SUDO Systems

That's because of the sudo config. I used the following question/answer to get me going: https://askubuntu.com/questions/128413/setting-the-path-so-it-applies-to-all-users-including-root-sudo

Basically:

The manual page for sudoers states:

   env_reset       If set, sudo will reset the environment to only contain
                   the LOGNAME, MAIL, SHELL, USER, USERNAME and the SUDO_*
                   variables.  Any variables in the caller's environment
                   that match the env_keep and env_check lists are then
                   added.  The default contents of the env_keep and
                   env_check lists are displayed when sudo is run by root
                   with the -V option.  If the secure_path option is set,
                   its value will be used for the PATH environment
                   variable.  This flag is on by default.

and this is how to address it:

So, you can do the following to maintain variables when using sudo

sudo visudo

this will open sudo settings for you. Then per what I did you add the following below

Defaults secure_path="blah"

Defaults env_keep +="VARIABLE VARIABLE VARIABLE"

(EXCLUDING PATH as it is set by secure_path) and those are just single spaces between each variable if you wish to have more than 1 maintained.

and what this does is tell sudo which env variables to keep and not disregard.

When done hold ctrl and hit o for Write Out hit enter and say yes to save [even though it specifies a tmp file this is OK it will be written back to the main config just say yes when asked if you wish to overwrite].

That should allow you to maintain whichever variables you wish (a big one being JAVA_HOME and also http_proxy if you use a proxy).

So it should look something like below including your specified variable:

Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin/bin"
Defaults        env_keep +="GRAILS_HOME"

and to verify it takes exit any open terminal windows and re-open one and run 

echo $GRAILS_HOME

It should be what you set, now issue

sudo echo $GRAILS_HOME

and it should now remain unchanged.

The Grails_home reference is from me helping another user on ubuntu communities so just sub that with the name of your variable.

Improve this answer
3
  • sudo is not su, or at least it isn't on most systems. They do not share a configuration file.
    – Zoredache
    Nov 7, 2014 at 20:04
  • The fact that sudo is preferred is irrelavent. The OP is asking why the su binary on his system changed behaviors after patching bash. His config was working, only bash changed. Your answer and these comments are not related to the question being asked.
    – Zoredache
    Nov 15, 2014 at 9:35
  • and I updated the answer so it gives them that information directly. See upper part of my answer now I have answered it for both SU only systems and left the Sudo piece for those user's that was the point I was trying to get across before for su only it is usally an alias in bashrc sorry if you did not read it the way I intended. Should be much clearer now.
    – Pariah
    Nov 15, 2014 at 9:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .