UNIX for Advanced & Expert Users

Ensure that env.sh exports the defined variables!
(Otherwise they are just internal shell variables - not environment variables.)
Check with

Code:

env | grep -w LD_LIBRARY_PATH

Yes env variables are being exported. That is why when I print LD_LIBRARY_PATH has the right value. But I read online that the reason ldd cannot find the library file even though LD_LIBRARY_PATH has the path is because when setuid binary is used, for security reasons Linux and most modern unix systems ignore LD_LIBRARY_PATH variable because of the risk that some usercould point LD_LIBRARY_PATH to some nefarious library file and use the C setuid binary to run some malicious code.
In my case

scriptwrapper.ksh contains

#!/usr/bin/ksh
setuidbinary script.ksh

script.ksh contains

#!/usr/bin/ksh
. <path>/setenv.ksh
sqlplus -s ......

Since C setuidbinary is setuid to owner cdds, when user cddsoper tries to run scriptwrapper.ksh, even though LD_LIBRARY_PATH is exported the right value by setenv.ksh, when sqplus ORACLE binary is run, loader cannot find the .so libraries used by Oracle sqlplus binary because those paths are defined in LD_LIBRARY_PATH variable which is disabled.

I even tried specifying the Dynamic library path at compile time into the C binary setuidbinary using

gcc setuidbinary.c -Wl,-rpath=/app/oracle/lib -o setuidbinary

But even that doesnot work because when I run setuidwrapper.ksh as cddsoper user, I get the same "libsqlplus.so not found" error.

Does anybody know any other workaround for this that tells the linker to look exactly in /app/oracle/lib for libsqlplus.so when user cddsoper calls the setuid binary setuidbinary even if it ignores LD_LIBRARY_PATH for security reasons ?

Much appreciated.

thanks

I would be concerned that someone will run:-

Code:

setuidbinary rm -r ~cdds

It is leaving a fairly big gap in security. The better way is to use sudo as advised by MadeInGermany.

It's not hard to manage and removes the risk of coding setuidbinary as a matter or course. Making things easy often means making it easy to make a mistake.




Robin

sudoers is owned by root, that's an administrative obstacle here.
I have understood that LD_LIBRARY_PATH is set after the suid - and that should work!
Please test with the env command (not print/echo that works for internal variables, too)!
Further, your setuidbinary.c might need a
setuid(geteuid())
.

Hello MadeInGermany,

As suggested by you i used env and here is an interesting observation
Inside testremove.ksh I added the following lines

Code:

#!/usr/bin/ksh
export LD_LIBRARY_PATH=/app/asset_control_shared/DEV1_acdev1_usl20028171/ac/lib
echo "LD_LIBRARY_PATH using echo====$LD_LIBRARY_PATH"echo "Printing LD_LIBRARY_PATH value using env begins"
env|egrep '(HISTSIZE|LD_LIBRARY_PATH)'echo "Printing LD_LIBRARY_PATH value using env end"
/app/asset_control_shared/DEV1_acdev1_usl20028171/ac/bin/waitdb.ORACLE

First I remove setuid on invoke_shellscripts binary as below (owner acdev1)

Code:

-rwxr-x--x 1 acdev1 rdgac 8612 Jan  3 11:53 invoke_shellscripts
-rwxr-x--- 1 acdev1 rdgac  526 Jan  3 18:11 testremove.ksh

Then as another user acdev2 I ran from commandline

Code:

./invoke_shellscripts ./testremove.ksh

I got the following output:

Code:

LD_LIBRARY_PATH using echo====/app/asset_control_shared/DEV1_acdev1_usl20028171/ac/lib
Printing LD_LIBRARY_PATH value using env begins
HISTSIZE=1000
LD_LIBRARY_PATH=/app/asset_control_shared/DEV1_acdev1_usl20028171/ac/lib
Printing LD_LIBRARY_PATH value using env end

Now I added setuid bit to invoke_shellscripts binary as follows

Code:

-rwsr-x--x 1 acdev1 rdgac 8612 Jan  3 11:53 invoke_shellscripts
-rwxr-x--- 1 acdev1 rdgac  526 Jan  3 18:11 testremove.ksh

Now I reran this from command line

Code:

./invoke_shellscripts ./testremove.ksh

And this time I got following output suggesting that when setuid bit is set, LD_LIBRARY_PATH is ignored. As you can see echo correctly prints the value of LD_LIBRARY_PATH set in the 1st line of the script however env doesnot have it. It shows only HISTSIZE from the env|egrep command.

Code:

LD_LIBRARY_PATH using echo====/app/asset_control_shared/DEV1_acdev1_usl20028171/ac/lib
Printing LD_LIBRARY_PATH value using env begins
HISTSIZE=1000
Printing LD_LIBRARY_PATH value using env end

testremove.ksh is the one that will be calling the 3rd party binary that uses the library libuidata.so located in /app/asset_control_shared/DEV1_acdev1_usl20028171/ac/lib. How do you think this problem can be fixed using setuid( geteuid()) ?



thanks

The setuid() in the C code might need root privilege..
In fact Google only finds setuid(0).
It must be an undocumented feature in ksh to drop LD_LIBRARY_PATH environment if ruid!=euid.
My only idea is a shebang

Code:

#!/bin/ksh -p

And hope it will change this behavier.

Hi MadeInGermany,

The shebang with the -p option does not help either.
Linux just adamantly wants to ignore LD_LIBRARY_PATH variable when the calling binary is setuid regardless of how high up the call chain it is.
So i finally abandoned the setuid option and as suggested by you ealier and rbatte1, have decided to go with the SUDOERS option which works fine.
There is no such LD_LIBRARY_PATH restriction in SUDOERS which I am guessing is because SUDOERS limits access to a limited set of users that are added in the /etc/sudoers file for that script, where as setuid gives access to that binary to anybody who has a login on that unix box and so they want to mitigate the risk.
If users field is set to ALL in /etc/sudoers for a particular script or binary, then even SUDOERS poses a similar risk level as setuid.

thanks for your help.