I am very new to Unix so I want to apologize in advance in case my question is stupid.
I wrote a KORN script that I am planning to distribute to many users. This script contains sensitive information that the users should not see: user name and password to our database servers with payroll info.
Is there a way to hide ("obfuscate"?) parts (usernames/passwords..) or the entire script from the end users while still allowing them to execute it?
I am thinking that the right CHMOD command would do the trick i.e. something like "chmod ??? myscript.ksh...". I already did a "chmod 777 myscript.ksh" so I can run/test this script in my shell account but maybe I need to do something else? Do you guys agree? Is there a better option?
Chmod 777 means everyone can read, edit and execute the file. If you want to prevent others from reading the file, you can use something else with the chmod command, like "chmod 711 file" which will make the file executable for everyone, but only able to be read or edited by you, the owner.
Could you post the results of a
ls -ln script
or whatever you called your script. And a
id -u
The numeric uids control access. If your current uid as displayed by "id -u" is not zero or equal to numeric uid that owns the script you should not be able to run it.
Unless the interpreter itself is suid to either root or the owner of the script. My ksh is 555.
This is very odd. Yes, my uname -r is B.11.00.
What is the first line of your script? I have:
#! /usr/bin/ksh
First line of my script is: #!/bin/ksh <<==could THAT be the 'problem'? I do:
[acb@k903]/home/acb% echo $SHELL
/usr/bin/ksh
Could you post the results of a ls -ln script or whatever you called your script. And a id -u
[acb@k903]/home/acb% ls -ln dmake.ksh
-rwx--x--x 1 7073 50 1379 Jul 31 01:03 dmake.ksh*
[acb@k903]/home/acb% id -u
7073
The numeric uids control access. If your current uid as displayed by "id -u" is not zero or equal to numeric uid that owns the script you should not be able to run it.
Are you saying that, based on the results of "ls -ln dmake.ksh", I should not be able to run my script? I am so confused...
Unless the interpreter itself is suid to either root or the owner of the script. My ksh is 555.
You're signed on as numeric id 7073 and numeric id 7073 owns the script. That means that you can read you own file. No surpise there, the user read bit is on.
Now log off and log back on as someone else. Make sure that your uid is different. That is "id -u" must return some number besides 7073. And it can't be zero either. Uid zero is root and has special powers. Once your uid is 7070 or something, now try to run that script which is continueing to be owned by uid 7073. Since the uid's do not match you should fail.
You said that tried this with 3 different logins. Do you have three logins all with 7073 as the uid???
No problem with /bin/ksh verses /usr/bin/ksh, they are the same file.
A suid program assumes the effective uid of it owner. A "ls -l /usr/bin/passwd" will show an example. Anyone can use that program to modify their password, but only root can actually write to /etc/passwd. Because the program is suid to root, it can do that.
Okay...I screwed up (forgive my language)! Only `chmod 777` was applied on `dmake.ksh` when I ran my 3 tests successfully and not `chmod 711` (I thought my brain was turned on?). As you wrote earlier, it is therefore logical that all can see, execute and/or edit it.
Now log off and log back on as someone else. Make sure that your uid is different. That is "id -u" must return some number besides 7073.
Correct. I logged in as user `egroup` and did this:
And it can't be zero either. Uid zero is root and has special powers. Once your uid is 7070 or something, now try to run that script which is continueing to be owned by uid 7073. Since the uid's do not match you should fail.
You are correct. It failed (`cannot open`). For all 3 users. I have now applied `chmod 711`.
You said that tried this with 3 different logins. Do you have three logins all with 7073 as the uid???
Nope...All 3 logins have different uid values.
A suid program assumes the effective uid of it owner.
"ls -l /usr/bin/passwd" will show an example. Anyone can use that program to modify their password, but only root can actually write to /etc/passwd. Because the program is suid to root, it can do that.
This shows me that I have to pay close attention when deploying a simple script to my users. Not considering every points e.g. which bit is on/off ... may lead to a lot of confusion. I am going to talk to my boss and explain to him the situation: I need more time to review the whole solution...
Possibly the best workaround for you is to transform your script into a C/C++ program with username/password inside. This is not good either, but may work out for you.
Another option you may think about is to write a dummy C wrapper which is made setuid to the script owner and invoke the script in the program. The script can then be made off limits to other users by using the permission bits. However, as of other setuid programs you need to program it very carefully or you are inviting even more problems.
But I agree, you should take a close examination of the whole situation and find out if you can evade this by using some alternative means if at all possible.