running script as root

[Jim Mickens_1]

I have a script that was originally set up under HP-UX 10.20 that allows my users to archive their jobs. What the script does is allows the user to enter the job and it's location, then the script changes the priveleges of all the files under the job so that everyone has access to them, compresses the directory and then moves the job directory to a file system designated for the archives. Due to the chmod command in the script, and the fact that the user doing the archive wasn't necessarily the user that owned the files, I had the file set to run as root (chmod 4755) under hp-ux. We're migrating the users to a RH Linux AS server, and the script, even though I have the same 4755 priveleges set on it, does not run as root, so the chmod won't work due to different owners of the files. Can someone help me figure out how to get this to work?

[Gopi Sekar]

you can use sudo which will run programs as root

all that user has to execute is 'sudo program'
you should have each allowed user name entry in /etc/sudoers file

do man sudo for more information

Regards,
Gopi

[Jim Mickens_1]

Isn't adding the users to the /etc/sudoers file going to give them access to other things as well? I'm not sure I want to be able to do that.

[Gopi Sekar]

No you can explicitly say which programs are allowed to run as root for each user. check man sudoers to find out how to acheive this.

eg:

Cmnd_Alias CMD = /path/to/program
User_Alias USER = user1, user2

USER ALL = NOPASSWD: CMD

NOPASSWD will allow user to run the command without giving their password

Regards,
Gopi

[Jim Mickens_1]

I'll look into it. Thanks.

[Wim Van den Wyngaert]

Did you change the owner of the file to root too ?

Wim

[Jim Mickens_1]

The owner of the file is root, with the group set as users:
-rwsr-xr-x 1 root users 6578 May 20 14:25 manarc.shl

Should I flip the group setting back to root?

[Stuart Browne]

Under Linux, you using SetUID or SetGID on a *script* won't work (i.e. starts with #!). It's purposely disabled.

Once upon a time, it used to work, but we're talking back in the 1.2 series kernel days.

These days, you either 'sudo' the entire script (as already suggested).

In any case, make sure the users do not have *write* access (i.e. 0511) to the script file, as this will allow them to do whatever they want under the guise of the script.