Shell Script using set-owner-id

[Lawrence Mahan]

I am trying to create a script that will execute command as another user. I created my script, chmod +s,-w and changed ownership to the new-owner. When the script runs is creates files with the new-owner but when it executes the needed command I get a error that the command must be executed by new-owner. It will not run the commands as the new-owner. What am I missing???

[Alan Riggs]

What is the command you are trying to run inside the script?

The fact that files are created under the new owner demonstrates that the setuid is functioning. The fact that your other program does not accept the newid implies that it is using a form of authentication which bypasses a change of userid. If you su to the newuser does the program work? If not, it may be checking the logname rather than the active userid (who am i rather than whoami).

[Lawrence Mahan]

This script does run properly when run by the new-owner. I am trying to run 'informix' tbtape commands so I need the script to be owned by either 'root' or 'informix' for the commands to work. However do to the security requirments of the customer I can not have the login that starts the commands be 'informix' or an 'informix' synonym.

[Tim Malnati]

The users running the commands have to have execute permissions on this file also. Permissions should look like -rwsr-x---. The users involved need to have permissions in either /etc/passwd or /etc/group for the same group as the process. To prevent requiring the use of newgrp if this group is not their standard group, either link /etc/logingroup to /etc/group or explicidly permit them in /etc/logingroup also.

[John Palmer]

Larry,

Alan Riggs is correct in stating that the problem is in the way that the target program is checking which user it is running as.

The suid technique changes the 'effective uid' of the process but not the 'real uid'. If the program checks the 'real' rather than the 'effective' uid then it isn't going to work. An example of this is the command 'lvsplit' which insists on being run as 'real' root, you can't run it from a root suid script.

One way around this is to have a 'daemon' process running as the required uid which communicates with your process (via signal or named pipe) and issues the required command or script. The security issues of this need to be considered carefully though.

Hope this helps,
John

[Jacques Simon]

One (simple) way of solving this problem is to use:
su - -c "<script to be executed as user user1>"
in a script that is executed as user root.
This has also the advantage that the rigth environment is automaticaly set thru execution of profiles.
But if the initial script (the one executed as user root) is started by cron, you must beware of "terminal commands" (like stty and tset) in those profiles!

[Anthony deRito · Accepted solution]

Larry,

You cannot use SUID to root on a shell script. HP recommends doing the following:

1. Create a simple C proigram that contains the calls you need to make. Call it setuid_shell.c

2. Compile the program using:
cc setuid_shell.c -o setuid_shell

3. Change the permission and set the user id by typing:
chmod 4777 setuid_shell

4. Change the owner to root by typing:
chown root setuid_shell

Now, the user can run this program as if they were the root user.


Tony

[Alan Riggs]

Have you tried implementing sudo? It is fully configureable and would allow you to define a set of users who can execute only this program with root/informix authority.