Shell Programming and Scripting

Hi Corona688,
I think you're missing the point.

You (Corona688) are writing a shell script that you (or other people) will run to access a database. Your database administrator (waavman) wants to create a file that you can't read that will contain the paths and passwords to the database you are trying to update with your script. If people other than you are going to run your script, they need to be able to read your script. So, if they are going to run your script they can also copy it and make changes to it and run their own copy of your script.

Some of us don't see what advantage waavman gains from keeping you from reading the file containing this data since you (or anyone else running your script) can change your script and see the hidden paths and passwords being used by your script anytime you (they) want.

We see the need to restrict reading that file to the legitimate users of that database. That can easily be handled by creating a group with members being the list of users who need to access that database. Then assign that group as the group ID of the file and make the file mode 640 with the database owner being the owner ID. No need for set-UID or set-GID code and no need for sudo; same security.

Which is why I spent the last 4 pages or so suggesting a sudo-based solution to isolate the env file and the script from its users permission-wise instead of letting him rube-goldberg it.

This Response is to both Don and Corona.
First to Don's response that I set the envfile to 640 and make only people who can see the envfile be part of the owner's group.
The requirement at my place is slightly different. There are about 25 support folks who will be running several scripts that source this envfile daily. They should be able to run these scripts without any issues. These scripts do several things in the background like connect to Database, connect to informatica server, run ETL workflows write to database etc. However none of the these 25 support personnel should be able to login to the database and do any manual updates. Their job is just running the scripts if any of them have failed or stopped for some reason.
Only the admin and a small group of users who code the scripts and DB stored procs and ETL workflows, should be able to view the envfile.txt since they would have to login to the database and perform DML and DDL operations. This is where the requirement of 25 users being able to source the envfile.txt despite not having read access to it comes up.

Next part of this response is directed to Corona.

Corona,

He is an extract from my previous post 3 days ago where in I tried the set -x option on Darwin OS 10.8

I am referring to my post 3 days ago in which I tested that sudo does not inherit set -x option. That is fine. But i noticed another problem.
As you can see from my previous post above, the script invoked by 'otheruser' which calls the admin users's script with sudo is call_adminusers_restrictedsudocommand.ksh . While I got overwhelmed with trying to verify that set -x is not inherited by Sudo, I forgot to confirm at that time that sourcing the env file using sudo call to the admin script DOES actually propagate the environment variable exported inside the envfile.txt to the 'otheruser' script. When i checked now it actually DOES NOT propagate. Am i missing something here ?

Here is a demo:

Contents of Env file testenvfile.txt that exports env variable ADMINHOMEDIR

Code:

$ cat testenvfile.txt 
export ADMINHOMEDIR="/Users/admin"

Admin user's script which sources the environment file and to which sudo access is added in the /etc/sudoers file so that 'otheruser' can run it through sudo

Code:

$ cat test_xtrace_withsudoaccess.ksh 
#!/bin/ksh
. /Users/admin/testenvfile.txt

'Otheruser' script which calls above admin script with sudo and tries to
print the value of env variable ADMINHOMEDIR

Code:

$ cat call_adminusers_restrictedsudocommand.ksh 
#!/bin/sh
set -x
sudo /Users/admin/test_xtrace_withsudoaccess.ksh
echo "ADMINHOMEDIR============$ADMINHOMEDIR"

Output of running above script shows that ADMINHOMEDIR is not set for some reason

Code:

$./call_adminusers_restrictedsudocommand.ksh
+ sudo /Users/admin/test_xtrace_withsudoaccess.ksh
+ echo ADMINHOMEDIR============
ADMINHOMEDIR============

So why is the environment variable set by admin script test_xtrace_withsudoaccess.ksh not available inside the 'otheruser' script that calls it through sudo ? Am i missing something here ?

thanks
waavman

OK. That rules out my suggestion.
As with any other command that you run as a separate process, sudo creates a separate shell execution environment. When sudo exits, that execution environment disappears and does not have any effect on the current shell execution environment.

If you're going to use sudo, the script that you invoke with sudo needs to handle entire database transactions (login, perform transaction, print any results that need to be returned to the rest of your script); it can't just set environment variables, unless you're willing to let unprivileged users see the all of the variables needed to access and modify the database.

Hi Don,

Yes granting sudo access to the entire script would be the right solution. But as I had mentioned in thread #11 of this post this would not be practical in my case because we have around 300 scripts which source the env file. So this would mean granting sudo access in the /etc/sudoers file for each of 300 scripts to be run as masteraccount.
So that I why I tried if just granting sudo access to a single script that just sources env file would work. But that Does not seem to work. So I guess for now I will have to live with the eval `setuid perlscript option`

thanks

You must have changed how you ran it.

The correct procedure is sudo -> script, script sources file, script uses variables, script quits and takes everything with it, leaving the variables unavailable to the user and hence fully protected.

The variables are only available inside 'script'. That is the entire point. If they ended up in the user's environment, the user could just take them, so, you can't do that.

Environment files don't work that way. If they did, that solution would be no good, because by definition it would be giving access to your users. You must not run these scripts as a user they control.

It's not an "option". It's a screen door, painted safety orange in the hope that hackers will overlook it because it's just too obvious. It is dangerous and irresponsible.