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
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
If I change it to:
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