I have a script that start the http deamon. This script has got owner and group as root and I have put a setuid on it.

That scripts executes from normal user fine. Now suddenly this script has stopped functioning.

I want to know:

1. The effective uid get propogated to other script called by this script.

2. Is there any way to stop this propogation, If yes how this can be done.

My distro is RHEL.

AFAIK
Setuid is for binary programs. The #! in the scripts just tell the shell what program to use to run this script.
Now since you might have given something like #!/usr/bin/perl, what effectively gets translated is that shell
executes this as

/usr/bin/perl <program name>
so eventhough the program script is setuid, it will not get executed as per the setuid principle.
If this were a compiled self-executable, then the setuid will work.

so the answers are
1. the effect uid is the uid of the user who is running the script
2. ???

Well setuid in perl is possible.

This took me a while to figure this out too. But, on Fedora.

Then the script will launch /usr/bin/suidperl not /usr/bin/perl even when the shabang is still #!/usr/bin/perl.

Try this little script.

I saved as suid.pl and then

Then run it!

I'm assuming this requires perl to be suid-root, which sounds like a horrible idea. The only way you can suid a script is if the interpreter is suid (or it's otherwise run as root) and it supports such uid changes.
Kevin Barry

PS The only exception to "don't make an interpreter suid" might be a wrapper program (i.e. < 100 lines or so) that does the following:

1. Checks the ownership of the script.
2. Checks the suid flag of the script and the "nosuid"/"noexec" flags of the mount containing the script.
3. If suid execution is acceptable, set the real and effective uids to the owner of the script. Otherwise, set the effective uid to the real uid.
4. execve the actual interpreter, which isn't suid.

This, of course, means the script isn't actually suid; it just makes the wrapper change uids before executing the interpreter. The difference is that the interpreter isn't capable of changing to another uid unless it's running as root already. I'd make sure all of the above were true before installing any suid interpreter.

Given
it sees to me that setuid is redundant; its already root.
If you want to run it as root from another user, sudo would be safer.
As per ta0kira, try to minimise the number of setuid programs on the system.