UNIX for Advanced & Expert Users

I have written a shell script function, this function reads a encrypted a file and does some processing. I want to give execute permissions to others but I don't want to give read access to the shell script function. Since the shell script function know how to open the encrypted file so that's why I don't want to allow others to see the content of shell script file. I want this kind of permissions (rwxr-x--x myscript.ksh)
The problem is other users get permission problem, since shell can't read file so it can't execute as well.

Is there any easy method so that the others can execute but can't read the shell script file. I know writing C programme will solve this problem but I am not good in writing C programme.

Thanks
Sanjay

Yeah, that's always a tricky one...

You can create a wrapper script for your original script with setuid permissions.

Ie: wrapperscript.sh has 4755 permissions and your readme.sh script has 111 permissions.

You just need to do some checksumming or validation when using setuid wrapper scripts as it can open up security holes if not done properly. A very simple example would be to make sure you use the fully qualified path to your file reader script...

That's all I can think of off the top of my head

Good luck.

No Unix that I know of will execute a shell script setuid, even if the setuid bit is on.

You could write a wrapper script, though, using sudo, and if you set up the sudoers file correctly, you should be able to let them execute, but not read.

Thanks Guys,
I was able to write a C wrapper script and it looks like it works perfect.


Sanjay


#include <stdlib.h>
#include <stdio.h>
#include <string.h>
/**********************************************
This is the wrapper script
How to Compile : gcc f_getSQLPLUS.c -o f_getSQLPLUS
: chmod 4711 f_getSQLPLUS

***********************************************/

int main(int argc, char *argv[]) {
char argbuf[4096] = ". /opt/app/oracle/local/bin/oralib.ksh ; ";
int i;

for (i = 0; i < argc ; i++)
{
strcat(argbuf,argv[i]);
strcat(argbuf, " ");
}

//printf("%s", argbuf);
system(argbuf);
}

Here's an example. Script A and script B. Script A is set with 4755 "root : other" permissions, script B is set with 100 "root : other" permissions:

-rwsr-xr-x 1 root other 123 Mar 29 15:19 a
---x------ 1 root other 119 Mar 29 15:19 b

Script A is as follows:

#!/bin/ksh
echo "\nIn A"
echo "id --- \c"
id
echo "whoami --- \c"
/usr/ucb/whoami
echo "who am i --- \c"
who am i
./b

Last line, you'll see that A calls B.

Script B is as follows:

#!/bin/ksh
echo "\nin B"
echo "id --- \c"
id
echo "whoami --- \c"
/usr/ucb/whoami
echo "who am i --- \c"
who am i

Changing to login testme and attempting to run B:

$ ./b
ksh: ./b: cannot execute
$

And running A:

$ ./a

In A
id --- uid=100(testme) gid=20(testme) euid=0(root)
whoami --- root
who am i --- root pts/7 Mar 29 15:10 (machine hidden)

in B
id --- uid=100(testme) gid=20(testme) euid=0(root)
whoami --- root
who am i --- root pts/7 Mar 29 15:10 (machine name)
$

Fairly simple and quick test to setup . Notice the effective uid and read uid are different.

Glad you got your script working...

The use of /usr/ucb suggested that you are using SunOS. I tried a similiar script and verified that SunOS 5.6 does indeed support setuid shell scripts. Whoa! I didn't know that...

I tried the following script also setuid to root and invoked by an ordinary user:

Code:

#! /usr/bin/ksh
sleep 999
exit 0

And I tracked down the ksh command in "ps". It showed up as "/usr/bin/ksh /dev/fd/3". Any unix version with a fd psuedo-filesystem can use the same trick. This closes that nasty setuid shell script problem completely. This doesn't mean that setuid shell scripts are totally safe, but they are as safe as they would be if sudo invoked them.

Well, golly, I stand corrected...