Shell Programming and Scripting

Hi,

I am running this on Redhat 5.10
I have a simple test script called test.sh which has the following
contents and it uses the BASH shebang.
-------------------------------------------------------------

Code:

#!/bin/bash
eval `/tmp/filereader.pl /tmp/envfile.txt`
echo "TESTPATH=$TESTPATH"

Inside /tmp/envfile.txt there are the following contents
------------------------------------------------------

Code:

export BASEPATH=/masterdir
export TESTPATH=${BASEPATH}/subdir

When I run test.sh I get the following INCORRECT output
-------------------------------------------
TESTPATH=/subdir

But if I change the shebang line to point to Korn Shell as
#!/bin/ksh and rerun test.sh I get the following CORRECT output
--------------------------------------------------
TESTPATH=/masterdir/subdir

So when I run with Korn shell I get the correct output but when I run with BASH it is not reading the contents of $BASEPATH into the TESTPATH variable. Can you please explain why .

Much appreciated.

Thanks
waavman

---------- Post updated at 02:11 PM ---------- Previous update was at 01:55 PM ----------

Missed out on mentioning what /tmp/filereader.pl does in my previous question.
It is just a simple perl script that opens the file supplied to it as argument and prints its contents line by line.

Of course, the obvious fix would be to change:

Code:

eval `/tmp/filereader.pl /tmp/envfile.txt`

to:

Code:

. /tmp/envfile.txt

But, assuming you are trying to do something with your perl script other than emulate cat, what happens if you change it to:

Code:

eval $(cat /tmp/envfile.txt)

so you can determine if the problem is an interaction between your perl script and bash eval with command substitution or if there is just a problem with bash eval with command substitution.

If the cat works, we'll need to see the contents of /tmp/filereader.pl...

Just to be sure that something in the environment isn't affecting the difference in behavior between bash and ksh, please also insert:

Code:

TESTPATH=before

as a new line before the eval command in your script.

Hi Don,

I am using perl script to read the envfile because eventually I would like this shell script to be used by other users who donot even have read access to /tmp/envfile.txt (using setuid bit that Perl supports)
For now however the userid that this is being run with does have read access to /tmp/envfile.txt. Or else it would not have worked even with KSH.

I tried using eval with cat instead of the perl script as you suggested.
But I notice the same behaviour as shown below.

Code:

#!/bin/bash
#eval `/tmp/filereader.pl /tmp/envfile.txt` 
eval $(cat /tmp/envfile.txt)
echo "TESTPATH=$TESTPATH"

And I get the following INCORRECT output where $BASEPATH is not substituted in the value of $TESTPATH
--------------------------------------------------------
TESTPATH=/subdir

But when I change shebang to #!/bin/ksh as below

Code:

#!/bin/ksh
#eval `/tmp/filereader.pl /tmp/envfile.txt` 
eval $(cat /tmp/envfile.txt)
echo "TESTPATH=$TESTPATH"

I get the correct output
---------------------------
TESTPATH=/masterdir/subdir

I tried adding TESTPATH=before before the eval `perlfile...` and also before eval $(cat...). It doesnot use that value of TESTPATH since it overwrites it with the value of TESTPATH from the /tmp/envfile.txt in both KSH and BASH.

As for my perl script /tmp/filereader.pl its a simple script that just reads form the input file argument and prints one line at a time

Code:

#!/usr/bin/suidperl
$envfilename=$ARGV[0];
open(FILEHANDLE,"<$envfilename") || die "Cannot Open file $envfilename";
while (<FILEHANDLE>)
{
        $lineread=$_;
        chop($lineread);
        printf("%s\n",$lineread);
}

However as you can see it does NOT seem to be an issue with the Perl script since the same variation of behaviour is exhibited between bash and ksh even when using eval $(cat /tmp/envfile.txt)


thanks
waavman

Perl does not "support setuid". It is not perl's job to elevate permissions. Either the operating system gives scripts elevated permissions on exec or it doesn't, and on most systems --

Code:

$ cat ./setuid.pl
#!/usr/bin/perl

print $<, "\n"; # Print UID
print $>, "\n"; # Print EUID

$ ls -l ./setuid.pl

-rwsr-xr-x 1 root root 49 Sep  2 15:53 ./setuid.pl

$ ./setuid.pl
1004
1004

$

-- it doesn't. Same as any other script.

If you are looking for security, cramming unescaped anonymous scripts into eval is hardly the way to go anyway. That's kludgy, and you've only shifted the problem one further down -- now you have the same problem of stopping people from running filereader.pl...

So my suggestion is to rip out eval and just source the script properly. Put the script and the profile under different ownership to protect them, and only let sudo run it.

Try

Code:

eval "$(cat /tmp/envfile.txt)"
echo "TESTPATH=$TESTPATH"
TESTPATH=/masterdir/subdir

as opposed to

Code:

eval $(cat /tmp/envfile.txt)
echo "TESTPATH=$TESTPATH"
TESTPATH=/subdir

In addition to RudiC's suggestion, here are a couple more interesting tidbits...
If you change the contents of /tmp/envfile.txt from:

Code:

export BASEPATH=/masterdir
export TESTPATH=${BASEPATH}/subdir

to:

Code:

export BASEPATH=/masterdir;
export TESTPATH=${BASEPATH}/subdir

your code behaves as expected with both bash and ksh with or without the double quotes around the command substitution.

And, if you change the contents of /tmp/envfile.txt to:

Code:

export BASEPATH=/masterdir TESTPATH=${BASEPATH}/subdir

bash fails with or without quotes around the command substitution and ksh succeeds in either case.

In the case of:

Code:

export BASEPATH=/masterdir TESTPATH=${BASEPATH}/subdir

the standards say that operands should be processed in the given order (unless the DESCRIPTION or OPERANDS sections state otherwise), so it appears that bash (with or without the --posix option) does not conform to the standards in this case.

Hi Rudi, Don,

Thanks for your great Discoveries. Solution provided by Rudi is very easy to implement and it works even with the Perl file reader code I have. Solution provided by Don is also very helpful. However in my case since envfile.txt is being shared across multiple users, I would prefer to make local changes to my script by adding "" in the eval command as in

Code:

eval "`/tmp/filereader.pl /tmp/envfile.txt`"

Also Don I was curious how come in bash the ';' at the end of each line in /tmp/envfile.txt makes it work without "" in eval ? Each entry in my envfile.txt are anyway newline-separated or on a separate line. Isn't that good for bash to understand that each export command in the envfile.txt is a separate export command that i needs to process separately as it is separated by newline. What is the significance of ; as opposed to newline in bash ?

thanks