[Techtalk] sh/perl/setuid

Nicole Zimmerman colby at wsu.edu
Mon Jan 14 20:10:05 EST 2002

> I assume you're being very, very careful with those scripts, and that
> no user you don't want to can get access to it, and that neither the
> perl script or the shell scripts accept any input from the user
> whatsoever.

Of course. That is why I do not want to make the *entire* script setUID. 

> Is that the actual system command you're using?  In that case I don't
> believe the setuid bit on $path_to_shell_script is paid attention to,
> because the OS considers sh to be the executable, not
> $path_to_shell_script.

If I change it to: 

system("$path_to_shell_script restart"); 

it has the same effect. 

> There is another issue that bash sometimes silently drops root
> privileges when it thinks it's running setuid.

Whatever it is, it's silent.

> Also, many systems, including Linux, do now allow setuid scripts.

Running the script on the command line as another user (./shell_script
restart) has the same effect as running it from the perl script.

It is possible this is the case, I do recall trying to set up setUID shell
scripts to restart services before and gave up -- I ended up using sudo.
Unfortunately (fortunately?) this system is to be WAY more secure than
that one, and putting sudo on it frightens me... although I suppose with a
good sudoers I could possibly restrict the access enough that the user
would not be able to do anything but those few commands I need.

> The way to get around this is to write a really tiny setuid binary
> that does 1 thing: executes the script (using the full path) with the
> bare minimum environment necessary.

I was hoping to keep it simple ;o) Unfortunately simple is not always
secure, correct, or the best way.


More information about the Techtalk mailing list