running "chown" within a SETUID script

[Marc Ahrendt]

i have a script that i want users to run as root, all works except the chown command fails saying "Not owner" for each file a chown is attempted against

1) i set the script permissions to 4555
2) CHOWN is set globally

i know about sudo and the fact that i can run this script as a root cronjob ...just wanting to know why chown does not work within a SETUID script

is the command "chown" not fooled by the SETUID bit?

[John Poff]

Hi,

Using the CHOWN privilege just allows a user to 'chown' files that belong to them. Everyone gets that by default. It sounds like your set-uid script is running as root but doesn't have the effective user ID set for root, which is what the chown call is looking for.

From the chown (2) man page:

Only processes with an effective user ID equal to the file owner or a user having appropriate privileges can change the ownership of a file. If privilege groups are supported, the owner of a file can change the ownership only as a member of a privilege group allowing CHOWN, as set up by the setprivgrp command (see setprivgrp(1M) ). All users get the CHOWN privilege by default.

You could try running the 'id' command inside of your script to see if it will report what the effective user ID is while it is running.

JP

[S.K. Chan]

As far I know suid chown would worked in an suid script. I did a quick little test and it worked as I expected. My script is owned by root:sys and had r-sr-xr-x permission. I then ran it as user "skchan", had a line in the script that perform a chown on a temp file in /tmp and it did it for me. Put these 2 command in your script ..
1- whoami
2- who am i
1 returns "root" as the effective uid and 2 returns "skchan". What does yours return ?

[James R. Ferguson · Accepted solution]

Hi:

You say that "all works except the chown...". First, I agree with John and SK, if you add the 'id' command, does your script show that it has an effective uid of zero?

Make sure that you have specified the shell interpreter "she-bang":

#!/usr/bin/sh

...or...

#!/sbin/sh

Without this the script will not run as an suid script despite the permissions denoting this state.

Regards!

...JRF...

[Frank Slootweg]

Please realize that set-UID (and set-GID) scripts are a big security risks and *cannot* be made secure. As you yourself mention, sudo or cron are better solutions.

[Marc Ahrendt]

John: sorry i forgot to state the the script ownership is root:users

SK: thx for confirming that it should work ...i learned that "whoami" and "id" always return the real user name while "who am i" returns root as the user name

James: thx for the fix! i did not define the shell in the script ...awesome catch

Frank: can i make the SETUID script somewhat secure by setting the permissions to 4550. my thought is that if a hacker has the ability to modify this script then the hacker has the ability to do worse anyways....

FYI: below is the actual script ...James gave the fix in that i did not have this 1st line defining the shell
#!/bin/sh
cd /opt/tomcat/webapps/IDCNServlets/xml
chown webadmin:webgroup *.xml

[Frank Slootweg]

Marc, a set-UID script does not have to be writeable to be a security risk. As I said, they *cannot* be made secure, i.e. also not by making them non-writeable.

[W.C. Epperson]

Frank is right, but probably too busy to articulate why. Here's one discussion of how to do setuid scripts and also why you probably shouldn't:

http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html

[John Meissner]

you can run the script as root if you use a product such as sudo or Servicecontrol Manager. These are free and secure although a little more work that I think you are looking for here. But still a good inverstment (or your time) should you choose to use either.

[Marc Ahrendt]

thx Frank,, WC, and John ...that link WC gave explains well why my SETUID script works OK now as James indicated and also that i should not use it!