The script can only decode if it has read access to the private key, so it has to be run by that user or root. Admittedly, the LINUX culture had gone sadly root/sudo, and that is only not-root-user-safe and no-backdoor-file-access-safe.
Beyond that, the problem becomes like a movie player/file that only plays when conditions are met. Most of them have been hacked open.
There is password encryption, where the script has to ask for the password.
another option is to port the script into c program binary ... chmod 711 binary and place it in a protected directory ... users can then run the program at will without being able to read anything as long as they have the correct path ... encrypt all source code in a protected directory ... sample below runs hostname in shtest ... lstest is just a copty of /bin/ls ...
if taking this option, make sure you account for what the users may want to change (i.e., different file path, current time, logfile name, etc.) so there is no constant recompile and looking at the sourcecode ...
from regular user perspective:
otto@susegeek:/tmp> cd testdir
otto@susegeek:/tmp/testdir> ls -ld
drwxr-xr-x 3 root root 4096 Jun 28 15:48 .
otto@susegeek:/tmp/testdir> ls -l
total 4
drwx--x--x 2 root root 4096 Jun 28 15:39 700
-rw-r--r-- 1 root root 0 Jun 28 15:48 test1
-rw-r--r-- 1 root root 0 Jun 28 15:48 test2
-rw-r--r-- 1 root root 0 Jun 28 15:48 test3
-rw-r--r-- 1 root root 0 Jun 28 15:48 test4
-rw-r--r-- 1 root root 0 Jun 28 15:48 test5
otto@susegeek:/tmp/testdir> ls -l 700
ls: cannot open directory 700: Permission denied
otto@susegeek:/tmp/testdir> ls -l 700/shtest
-rwx--x--x 1 root root 33 Jun 28 15:21 700/shtest
otto@susegeek:/tmp/testdir> ls -l 700/lstest
-rwx--x--x 1 root root 112892 Feb 18 2011 700/lstest
otto@susegeek:/tmp/testdir> 700/shtest
/bin/ksh: 700/shtest: cannot open [Permission denied]
otto@susegeek:/tmp/testdir> 700/lstest
700 test1 test2 test3 test4 test5
otto@susegeek:/tmp/testdir> strings 700/lstest
strings: 700/lstest: Permission denied
otto@susegeek:/tmp/testdir> cat 700/shtest
cat: 700/shtest: Permission denied
otto@susegeek:/tmp/testdir>
from root's perpective:
susegeek:/tmp/testdir # ls -ld .
drwxr-xr-x 3 root root 4096 Jun 28 15:48 .
susegeek:/tmp/testdir # ls -ld *
drwx--x--x 2 root root 4096 Jun 28 15:39 700
-rw-r--r-- 1 root root 0 Jun 28 15:48 test1
-rw-r--r-- 1 root root 0 Jun 28 15:48 test2
-rw-r--r-- 1 root root 0 Jun 28 15:48 test3
-rw-r--r-- 1 root root 0 Jun 28 15:48 test4
-rw-r--r-- 1 root root 0 Jun 28 15:48 test5
susegeek:/tmp/testdir # ls -l 700
total 116
-rwx--x--x 1 root root 112892 Feb 18 2011 lstest
-rwx--x--x 1 root root 33 Jun 28 15:21 shtest
susegeek:/tmp/testdir # file 700/*
700/lstest: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.4, stripped
700/shtest: Korn shell script text
susegeek:/tmp/testdir # 700/shtest
susegeek
susegeek:/tmp/testdir # 700/lstest
700 test1 test2 test3 test4 test5
susegeek:/tmp/testdir #
the sudo method mentioned earlier works similarly, denying them the ability to read it, while letting you run actual shell scripts as whatever user you want.
You cannot keep anything safe from root. Period. No ifs, ands or buts. The sudo method is not the cause of this problem, simply an acknowledgement of it; if you can't deny them access to the files, don't bother!
Security via obscurity only protects you if your invaders are easily bored.