about the permission!

[leyearn]

the oninit and ontape commands which is ni informix datebase have the permission:rwsr-sr-x
why do two "s" exist in one permission !

[Sridhar Bhaskarla]

Hi,


The "s" in first three bits is "suid". When the program runs, it will run as the owner of that file irrespective of whomsoever started it.

The s in next three bits is "sgid". So, when the program runs, it will run with the group as the group of that file irrespective of the group of the person running it.

For ex., if you set the owner of this file to "root" and if you start it as an ordinary user, then it will run as root.

These may open security issues on the system.

-Sri

[Rajeev Shukla]

The first s means setuid. So when this command is run it is run as the owner of the file (doesn't matter who ever runs it)
And the second s means set GID, so when its is run it will be run as the group of that file irrespective of what group the user running the command belongs to.

This is soemtimes required coz when you run sucj commands and they try to access some files which do not belong to that group it will fail.

[Sundar_7]

There is something called real user ID and effective UID. under the normal circumstances without the SUID bit set, the real user ID and the effective UID of a process will be set the same

The effective user id is used to determine file access permissions. When Set user ID bit is set then the effective user ID of the process will be set to the user ID of the owner of the executable.

Setuid can be set as follows

# chmod 4755 filename

the filename will have permissions rwsr-xr-x

# chmod 2755 fileset

will set the SGID.

[Steven E. Protter]

take a look at the permissions of passwd

-r-sr-xr-x 5 root bin 45056 Nov 14 2000 /usr/bin/passwd


This is because the program needs to be able to update /etc/passwd, a file only root can change. SUID exists in this case to let a regular user update his password, which is in a file that user does not own.

In your case however, these programs have root priviledges. I know of very few reasons why a database program would need root priviledges.

This is a security hazard, because your database might be exploited to gain root priviledges and possibly control of your whole system.

Don't change it back however without checking with Informix support. Don't change it with the database running, you might crash it or lock its shared memory segments.

SEP