Shell Programming and Scripting

Please understand that setuid perl still leaves you with the problem of protecting the perl script instead of protecting the env file. You'd be better off just sourcing and protecting your script and env file alike with sudo.

Hi waavman,


I was perusing your post number #3 in this thread and I noticed your Perl snippet. While it is not part of the topic here, I thought of mentioning a few bits in that snippet that might need attention.

Since the year 2000, a modification was made to the way you can open a file in Perl, due to issues found in the way you have it right now.
The popular 2-arguments: global variable, "include redirection in the file name" was found troublesome.
A new way was introduced: 3-arguments with a scalar lexical variable.

Instead of:

Code:

open(FILEHANDLE,"<$envfilename") || die "Cannot Open file $envfilename";

It can be changed to:

Code:

open my $filehandle, '<', $envfilename or die ...

There is an error waiting to happen in that while loop:
The function chop() will happily and quietly remove the last character of at the end of line, whether is a newline character or not. The function chomp() prevents that.

The while loop block could be written, without loosing clarity, as:

Code:

while(my $lineread = <$filehandle>){
    chomp($lineread);
    do_something with $lineread
}

I do not maintain bash, so I can't say why putting in the semicolon works when a <newline> without the semicolon doesn't work.

If you compare the ksh -xv script trace output to the bash -xv script trace output when running your script, the difference in what the trace of the eval showed made me wonder if a semicolon would make a difference. So I tried it, and it worked. The bash trace output looked like it was executing the command:

Code:

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

after the command substitution, but it didn't export a variable named "export" either.

Even if bash is executing your script (without the double quotes) as:

Code:

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

both export commands clearly have to be evaluated by the the shell in order. And with those two export statements, the result should be the same whether or not the 2nd export is evaluated by the eval or processed as a stand-alone command. Furthermore, if you look at $BASEPATH after the eval completes (with or without the double quotes), you'll see that BASEPATH is set correctly. It just looks like bash executes the 2nd export command before it executes the 1st export command. And, that appears to me to be a bug.

Hi Corona,

Yes you are right. I just didnot communicate right. What I meant was that Linux supports setuid bit for C/C++ binaries / Perl scripts. It doesnot support it for Java programs or shell scripts.
So my idea is to remove read permission on the /tmp/envfile.txt for rest of world. One common user will be owner of the perl script and the envfile.txt.
So when any of the 50 users other than the owner will not be able to read the envfile.txt which has confidential information but they will be able to run the shell scripts and source it inside the shell scripts using the eval command because when eval runs, the perl script it will run as the owner and be able to read the hidden envfile.txt.

The example I have given for this discussion forum is just a dummy example. In reality we have around 300 shell scripts which source the envfile.txt and which several users other than the owner will run. With the sudo solution you provided, there would be two complexities:
(1) Each of the 50 users' userids' should be given sudo access to run the shell scripts as the owner id
(2) Sudo access has to be given to each of those 50 userids' to run each of the 300 scripts as the ownerid

This could get very cumbersome.
I agree that somebody can notice the eval "`/tmp/filereader.pl /tmp/envfile.txt`" command
within the shell scripts and be smart enough to run it from command line to view the envfile contents.
But at least it is slightly difficult than running a straight 'vi envfile.txt' that even beginners to UNIX OS are familiar

thanks

suidperl was an ugly insecure hack. Was, past tense: It has been amputated from modern Perl. It is liable to disappear any time you update your system, so really shouldn't be depended on.

That's rather the long way around... Why not do that to the shell script itself? You'd need sudo to do so, but that's kind of the point. You need some setuid C executable somewhere to bridge the gap, it might as well be one that's written very, very carefully.

So you'd have your original script, under some user, which can just do . /path/to/totally/secret/env.file

And in its place, in the file people run:

sudo -u secretuser /path/to/script.sh

And in sudoers:

%someusergroup ALL=secretuser NOPASSWD: /path/to/script.sh

...to allow users in 'someusergroup' to run /path/to/script.sh as secretuser.

I'm still missing the point. You want to have me execute a bunch of commands I can't read by placing those commands in a file (/tmp/envfile.txt) owned by someone other than me with permissions that don't allow me to read it. Then you create a set-UID program (in perl or C or C++). This set-UID program reads the file I can't normally read and feeds it into the eval command in my shell script:

Code:

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

Presumably I can read my own shell script which contains the above eval command.

Why doesn't the shell script:

Code:

#!/bin/ksh
cat <<-EOF | tee $HOME/my_copy
    $(/tmp/filereader.pl /tmp/envfile.txt)
EOF

copy the secret contents of your file onto my screen and into a file in my home directory?

If you want me to include your secret shell commands and run them as me in my shell script, you need to realize that your secret shell commands have to be readable by me.

Don,
Like you mentioned when "" is used with the eval command or when ; is placed after the BASEPATH assignment in envfile.txt, xtrace output shows that BASH executes the commands one after the other in the proper order. Else we cannot determine in what order it is executing looking at the xtrace output

As for the setuid solution I have come up with I understand that it is not a completely secure solution. Other users can view the envfile.txt contents by running the setuid script using eval `/tmp/filereader.pl /tmp/envfile.txt`.
But i just tbought until I come up with a more secure solution this would be at least safer than having no Setuid script at all and giving read permission to all to /tmp/envfile.txt and using . /tmp/envfile.txt inside the shell script.
When I refer to confidential information inside envfile.txt I am referring to database passwords etc. which are assigned to environment vairables that will be used within the script.

Corona,

As for your suggestion that i create a shell script filreader.sh owned by master account that has read access to envfile.txt and which is shielded from read/execute access by other users and which has inside it

Code:

. /tmp/envfile.txt

Now inside the main script test.sh that other userids can execute i include

Code:

sudo - masteraccount /somepath/filereader.sh

This would work.
But again it would expose a threat in that other user ids can use a simple hack in the form of a script like this which prints the contents of envfile.txt

Code:

set -x
sudo - masteraccount /somepath/filereader.sh

So the other optionwould be to add this in test.sh

Code:

. /tmp/envfile.txt

and then revoke read permission to other userids on /tmp/envfile.txt and revoke execute permission to other userids on test.sh and GRANT SUDO access to test.sh rather than create a separate filereader.sh and granting sudo access to the filereader.sh

So other users can then run

Code:

sudo - masteraccount test.sh

But I think if other users write a script like this with the set -x option, they can expose envfile.txt contents here as well. So I am not sure if this is secure as well.

Code:

set -x
sudo su - masteraccount test.sh

thanks