0

We have many legacy csh scripts that connect to our db2 database using "db2 connect to <table>" command. They do NOT use "db2 connect to <table> user <user> using <password>" explicitly, so the connection defaults to the user running the script.

We want to change the db2 connection from the user account running the csh script to a dedicated db2 account (called "dblegacy").

I tried writing a wrapper executable that would load/run as root, and then change account to "dblegacy" before executing the csh scripts. Only problem is Linux (ld.so) removes LD_LIBRARY_PATH environment variable from all scripts/files loaded after setuid() account change to "dblegacy" occurs. And, of course, the csh scripts require shared libraries.

So, I need a way of having "db2 connect to table" use or default to this "dblegacy" account.

Richard
  • 184
  • 2
  • 7
  • I'm really confused why clearing the `LD_LIBRARY_PATH` variable would cause your `csh(1)` scripts to fail -- if your `csh(1)` interpreter requires libraries that aren't in the `/etc/ld.so.conf` or `/etc/ld.so.conf.d/*` list of directories, that directory probably _should_ be in the list. – sarnold Dec 08 '11 at 00:55
  • Been there, tried that. :-) I made sure the directory was in the ld.so.conf file (I even tried it in the .d sub configs. No luck. ld.so seems to ignore all of those and only allow certain pre-determined base library directories. – Richard Dec 12 '11 at 18:38

2 Answers2

1

If you are executing the scripts as the dblegacy user (using su or sudo), then you need to make sure that the scripts are setting up the DB2 environment properly.

For csh, the script should have near the top of the script (i.e. before and DB2 commands) that looks similar to this:

# Initialize DB2 environment
source /home/db2inst1/sqllib/db2cshrc

The specific location of this file may vary depending on what user your DB2 instance is defined with. Normally this would exist in the user's .cshrc, so that may help you locate the proper location of the correct db2cshrc file.

Once you've added this line done, you should be able to, as root, run your script like:

su - dblegacy -c "/path/to/script.csh"
Ian Bjorhovde
  • 10,916
  • 1
  • 28
  • 25
  • The problem is that the process is being kicked off as a normal user and we need to change from that user to the dblegacy user. In order to do this an executable that is chmod +s and chown root is executed, and internally it calls setuid() to change to dblegacy user before exec'ing the csh script. ld.so then (for security) removes several environment variables. – Richard Dec 10 '11 at 01:06
0

This (so far) seems to be our way around the problem...

Invoking program: execve("/cvt/scripts/cvtwrap", argv[], envp[]) where argv[1] is the full path to the target script.

cvtwrap:

#!/bin/csh -fx

alias db2 "db2cvt `which db2`"
source /cvt/scripts/$*

Then whenever target script executes db2 it executes db2cvt (chmod +s as root) which does our setuid to dblegacy account before execve'ing the real db2.

Richard
  • 184
  • 2
  • 7