Hello folks,
I’m trying to find out how to make a script setuid root on RTP 6.1 on a
Wintel box. I am aware of the security risk, but it seems we have no other
way to implement this functionality. I have a script file, called “script”
for the sake of argument, and I have done an “su root”, then “chown root
script”, “chmod a+x script”, “chmod a+s script”.
Ls -l script shows the proper bits are set in the file attributes field.
Running the script shows the problem. Result is that it doesn’t work, the
commands within script fail with permission denied, exactly as if the
commands were run without root permission. It would seem that setuid is not
being allowed. If it were a normal Unix machine I’d go look at /etc/fstab
to see if setuid was disallowed on this volume at mount time. Is there a
similar function in RTP and where do I look for it?
Hello folks,
I’m trying to find out how to make a script setuid root on RTP 6.1 on a
Wintel box. I am aware of the security risk, but it seems we have no other
way to implement this functionality. I have a script file, called “script”
for the sake of argument, and I have done an “su root”, then “chown root
script”, “chmod a+x script”, “chmod a+s script”.
If it were a normal Unix machine I’d go look at /etc/fstab
to see if setuid was disallowed on this volume at mount time. Is there a
similar function in RTP and where do I look for it?
It isn’t fstab or anything similar. If you do a little test with
a simple C program, or even by copying /usr/bin/id to a local place
and manipulating its perms you’ll find it does end up with an euid of 0.
What it is, is our loader – it doesn’t really understand scripts, just
executables. So, when you try to run the script, it loads the /bin/ksh
executable which doesn’t have the setuid bits set, then this executable
reads the script file and parses it – but setuid bit is meaningless at
read time (and the process wouldn’t have perms to become root anyway).
There isn’t any really easy work-around. About the best I can suggest
is to write a little C program that basically does:
my_script.c
void main()
{
system(“my_script.script”);
}
Compile it & make it setuid root, etc. You’ll need one each my_script.c
for each script – making them custom to the script to be run for security
reasons.
Hope this helps,
-David
QNX Training Services
I do not answer technical questions by email.
It isn’t fstab or anything similar. If you do a little test with
a simple C program, or even by copying /usr/bin/id to a local place
and manipulating its perms you’ll find it does end up with an euid of 0.
What it is, is our loader – it doesn’t really understand scripts, just
executables. So, when you try to run the script, it loads the /bin/ksh
executable which doesn’t have the setuid bits set, then this executable
reads the script file and parses it – but setuid bit is meaningless at
read time (and the process wouldn’t have perms to become root anyway).
I thought 6.1 added support for hashbang, didn’t it?
But anyway, it works same way on Solaris. I think shells just do not
like scripts to be SUID for security reasons.