1

I have a simple bash script which modifies a environment variable that will be used by subsequent binary. Bellow my basic script:

#!/bin/bash
export DBROOT="NEW_DIRECTORY" 
export TERM=xterm
su  -c " <test_process> " - omni

DBROOT variable is used by "test_process" as environment variable. Also, DBROOT is defined with another value "OLD_DIRECTORY" as a global environment variable. The goal of the script is to force the "test_process" to use NEW_DIRECTORY value (exported value).

With the non patched bash version, the test worked. However, after patching the shellshock bug on the bash, test_process does not read the exported value of DBROOT neither the global environment variables. It's as if the "test_process" ignores exported and global variables.

I don't have the source code of "test_process". The bash version is version 2.05b.0(1)-release (rpm version is bash-2.05b-41.7.i386.rpm ) and I'm running on Red Hat Enterprise Linux AS release 3

Update: After recompiling the bash 2.05b last sources by setting compile-time definition

#define NON_INTERACTIVE_LOGIN_SHELLS

the script worked again. Without this define bash misinterpreted the - character after su command

Mou
  • 23
  • 4
  • The final, accepted patch for shellshock moves exported functions into their own namespace (and fixes a bunch of parser bugs). I find it somewhat difficult to believe that it would have any impact on your code here, though of course whoever was backporting to RHEL3's ancient shell could have made some mistakes. Also, `su` in general has a lot of moving parts -- there's no shortage of things that could go wrong outside the shell. – Charles Duffy Oct 21 '14 at 15:53
  • 1
    Anyhow -- if you want to determine with certainty that `su` isn't the problem, just take it out, and see if you can reproduce; if you can produce the problem by just running `bash` at the end (instead of your `su` command) and seeing if `DBROOT` is set. Should in in fact be unset at that time, then (and only then) you know that it really is a bug in your distro's shellshock patch, not something happening elsewhere in the system. – Charles Duffy Oct 21 '14 at 15:54
  • 2
    `su` generally intentionally dumps pre-su environment variables as they would be security issues otherwise. It has a flag (two actually) to not do that: `-m`. Though I have no idea if that was all true back in whatever ancient version AS 3 is using. – Etan Reisner Oct 21 '14 at 15:58
  • You guess it right, if I run my script without `su` command the process inherit the exported and global variables. – Mou Oct 21 '14 at 16:05
  • Well I found the origin of my issue. It's not due to `su`. It's due to bash. I recompiled the source with `#define NON_INTERACTIVE_LOGIN_SHELLS /* Defined in config-top.h file */` and my old script worked – Mou Oct 21 '14 at 17:30
  • Eh? Bash doesn't even *know* whether `su` was passed a `-` character or not, so it can't possibly misinterpret it. I don't doubt that your problem was caused by a conflict between configured and desired behavior of `-i` and `-l`, but `su -` is only an indirect cause (by way of influencing the latter). – Charles Duffy Oct 21 '14 at 17:41
  • After debugging bash code, I found out that because of `su -` command, the sub-shell that was launched was `-bash` and not `bash`. So it's the `-` that leaded to this issue but I did'nt found out how. Thanks, for your response, that helped me a lot – Mou Oct 23 '14 at 15:38

1 Answers1

4

That's pretty ancient software you're using.

I suggest trying:

su -c "DBROOT='NEW_DIRECTORY' TERM='xterm' <test_process> " - omni

This moves the environment setting into the shell run by su, rather than relying on su to relay the environment.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • By setting `DBROOT` as you suggested, the `` inherit the value. However, others issues appears as other env variables are not inherited. By trying `su -c " "` the command inherited the global and exported variables. By investigating in the bash code, I found out that `su -c` command leads to launch `-bash`. So the `-` was the problem. By setting `#define NON_INTERACTIVE_LOGIN_SHELLS` in bash code, the problem was resolved. – Mou Oct 23 '14 at 12:26