What does the set-owner-id-on-file-execution mean

[Angela Swyers_1]

When setting the 's' in a chmod what exactly does it mean when you are executing a file. We are trying to get named users to be able to start an oracle database, but we want the user that started or the oracle user to be able to shut it down if needed. Is this the right thing to use?

[Mark Grant · Accepted solution]

The SETUID bit means that when a user runs the program, the program will run as if the user was the one who owns the file. For example an application that has the owner "oracle" and perhaps the group "dba" will run as the "oracle" user regardless of the user who runs it.

This can be a security risk so you really need to be sure that it's what you want to do.

If you want named users to startyour database you can either put those users in the "dba" group and use SETUID (in the example above) and remove read and execute permission for everyone else or you could use a tool like "sudo" where you can specify individual users who can run things as other users.

[Geoff Wild]

-rwsr-xr-x - setuid : the program will be run with effective user id being set to the owner of the file

man chmod
will give you more information.

Rgds...Geoff

[Bharat Katkar]

Just an addition:

Owner permissions of the file are temporarily given to the User accessing that file.

Regards,

[Michael Denney]

The use of chmod and setuid bit has been correctly explained above. I would recommend you look at using "sudo" for your purposes. "Sudo" will allow more control and accounting then setting the setuid bit. You can get sudo from the HP Internet Express bundle.
http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXIEXP1111

[Dani Seely]

Hey Angela,
To answer your question, yes, you can set the SUID bit on the appropriate start/stop scripts for your oracle database so that it will start/stop with effective user rights of a privileged user or application account, but as Mark pointed out, this can pose a security concern ...

Here's an excerpt from a security doc I authored regarding SUID:

Even if you prevent users from logging into the superuser (root) account, many UNIX programs need to run with superuser privileges. These programs are run as SUID root programs.

Unauthorized SUID programs present a security hazard. Many security holes have been discovered by people who have figured out ways of making a SUID program do something that it was not designed to do. If the superuser account is compromised then the system is left vulnerable.

It is extremely important, therefore, that any program that has the SUID bit set is of known origin and scope.

Enjoy

[Dani Seely]

Angela,
One thing I wanted to clarify, if you are concerned about the SUID files on your system (and there are SGID files as well that you should monitor), you can set up a cron job to do the following. My security script automates this, during a system install, to be done on a weekly basis ...

find / -type -f -perm -u+s -exec ls -lL {} \; >/tmp/SUID.out.$$

From this list you should review to see which files do NOT need the SUID setting and remove it. You should know the names of all SUID and SGID files on your system. If you discover new SUID or SGID files, somebody might have created a trap door that they can use at some future time to gain superuser access.

Hope this helps!