SUID not working

[Ben Wood_2]

I have the /opt filesystem mounted with the following:
/dev/vg00/lvol6 /opt vxfs delaylog 0 2

I created a wrapper script that has about 3-4 layers for starting up different 3rd party applications. The wrapper script and its underlying layers all exist under the /opt filesystem. I have SUID bits set on the underlying layers. But whenever I execute the wrapper script, it will run all underlying layers as the user that executed the wrapper script. I dont have the SUID bit set on the wrapper script either. My implementation works correctly on Solaris. I should mention that some underlying layers need to run as a different user than other layers. The use of
"su - user -c command" has provided me unstable results also. I would appreciate any help or ideas.

[steven Burgess_2]

Hi Ben

I think the easiest thing to do would be to attach your script for us to have a look at. Who actually kicks off the script ? root or another user ? If the user is not root then they will need a password to su , could this be causing your problem ?

Regards

Steve

[KapilRaj]

why SUID for child directories, does it really help you?.

setting it for a script also is of no use. do it for actual binaries (commands).

kaps.........

[U.SivaKumar_2]

Hi,

There are operating system like AIX ( some versions ) which does not support setting SUID in the shell scripts and other scripts for security reason.

If my memory serves me right , HP-UX is in that list. you can setuid only on binaries.

regards,
U.SivaKumar

[KapilRaj]

sorry to misuse the forums.... i could not locate his email id from Profile.

Shiva ??? from HCL ????. Can i have u'r email id ????.

kaps

[U.SivaKumar_2]

Hi Kapil,

sivakumr@rediffmail.com

regards,
U.SivaKumar

[Frank Slootweg · Accepted solution]

From exec(2):

[start quote:]

Note that the set-user-ID and set-group-ID functions do not apply to scripts; thus, if execlp() or execvp() executes a script, the set-user-ID and set-group-ID bits are ignored, even if they are set.

[end quote.]

[Shannon Petry]

You are required to do one of 2 things to get what you want.


First, and probably easiest is to write a C wrapper. setuid(), setgid(), and system() will do just fine.

If you dont know any C, dont want to learn, etc...
Sudo may be able to handle all the switching. Sudo used in this way would be very difficult, but work for the most part.

Note: su -c only works on a single command, and you have the same limits for the command string length as any shell command.

Regards,
Shannon

[John Palmer]

Setuid scripts DO work on HP-UX, certainly 10.20 and 11.00. They didn't work on 10.01 and don't work in AIX either.

The one requirement that you may be missing is that the script MUST have as the first line:
#!/usr/bin/sh (or #!/usr/bin/ksh)

Take the simple example script...
(/tmp) # cat jp.sh
#!/usr/bin/sh
id

(/tmp) # id
uid=101(oracle) gid=102(dba)

(/tmp) # ll jp.sh
-rwsr-xr-x 1 root dba 18 Dec 12 14:19 jp.sh

(/tmp) # ./jp.sh
uid=101(oracle) gid=102(dba) euid=0(root)

Regards,
John

[Shannon Petry]

John you are only partially correct. Read franks reply from HP. While you may be able to make very simple things work, depending on what your running and whether or not the executable you are launching is looking at UID or EUID makes a huge difference.

Not supported, probably will not work.

[Frank Slootweg]

Indeed (what Shannon says).

John, the behaviour you mention indeed *currently* works, but it is not documented and hence not supported (It *was* documented, and hence supported, in earlier releases.).

*Why* is it not/no_longer supported? Because set-UID (or set-GID) scripts are a security risk, because they *cannot* be made secure. I.e. you can plug many and perhaps even most, holes in them, but you cannot plug all holes. Because these holes are known, they pose a severe security risk. Hence a bad idea. Hence not supported.

[John Palmer]

Frank,

I agree with you, I was just pointing out that it *does* work.

Shannon,

The effective UID/GID is all that you can change with setuid and it's good for running most things - apart from those that actually check the real UID (LVM commands such as lvplit don't work with a EUID of root for instance).

Regards,
John

[Shannon Petry]

John,

I understand what you are saying, however I think you underestimate the amount of applications that dont look at your effective uid, and only at your uid.

I find the easiest way to handle this type of situation is a 5 minute c-code wihch sets your uid, gid, and makes a system call to run your app. Then you dont have to worry.

Scripts can have a sticky bit, but only excecutables can be truly run suid.

Regards,
Shannon

[Ben Wood_2]

All,

I understand what you guys are saying. I made this thing work on Solaris, but HP just wont accomodate this script in its current form. The SUID bit being ignored makes sense based on the results of my testing. It is a pretty ridiculous implementation that I wouldnt suggest. The problem is that we have several 3rd party apps that need to run their associated processes as different users.
A request was made to have one script that controls startup/shutdown of all apps.
I appreciate the good info that everyone has provided.

--Ben