Shell Programming and Scripting

On Solaris 5.8 after "chmod 711 testme" and switching to another user:

Can't open perl script "./testme": Permission denied

Is there a ksh--->exe tool? Perhaps that would be one way to be able to use permissions of 711.

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.

Can you please explain this last statement?

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:

[egroup@k903]/home/acb% ls -ln dmake.ksh (same result!)
-rwx--x--x 1 7073 50 1379 Jul 31 01:03 dmake.ksh*
[egroup@k903]/home/acb% id -u (different number!)
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 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...

Thanks for taking the time to teach me!

Al.

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.