Liunx UID and GID

A file has an owner that indicates who created the file. Also, the file has a group number that represents the group to which the file belongs, typically the group to which the file owner belongs.
If it is an executable file, at execution time, the file typically has only the permissions of the user who called the file. And setuid, Setgid can change this setting.
Setuid: Sets the permission to have the file owner in the execution phase of the file. The typical file is/usr/bin/passwd. If the file is executed by an average user, the file can be rooted during execution so that the user's password can be changed.
Setgid: This permission is valid only for the directory. After the directory is set, any user who creates the file in this directory has the same group as the group to which the directory belongs.
Sticky bit: This bit can be understood as an anti-delete bit. Whether a file can be deleted by a user depends primarily on whether the group to which the file belongs has write access to the user. If no write permission is available, all files in this directory cannot be deleted and new files cannot be added. If you want users to be able to add files but cannot delete files at the same time, you can use the sticky bit bit for the files. When this bit is set, the file cannot be deleted even if the user has write access to the directory.
Let's talk about how to manipulate these flags:
The operation of these flags is the same as the command to manipulate the file permissions, both of which are chmod. There are two ways to do this,
1) chmod U+s Temp--add setuid flag to temp file. (setuid only valid for files)
chmod g+s tempdir--add setgid flag for TempDir directory (setgid only valid for directory)
chmod o+t Temp--Adds a sticky flag to the temp file (sticky only works on the file)
2) Adopt Octal method. The general file is marked by three octal digits, such as 666, 777, 644, and so on. If these special flags are set, a set of octal digits is added outside of this set of numbers. such as 4666, 2777 and so on. The meaning of this set of octal digits three bits is as follows:
Abc
The A-SETUID bit, if the bit is 1, indicates the setting setuid
The B-setgid bit, if the bit is 1, indicates the setting setgid
The C-sticky bit, if the bit is 1, indicates the setting sticky
　　
After you set these flags, you can use ls-l to view them. If these flags are present, they are displayed in the original execution flag position. Such as
rwsrw-r--indicates a setuid flag.
rwxrwsrw-indicates a setgid flag.
RWXRW-RWT indicates a sticky flag.
So where did the original execution sign x go? The system specifies that if there is an X on the bit, these special flags are shown as lowercase letters (s, s, T). Otherwise, it is shown in uppercase letters (s, S, T)

To delete a file, you do not have to have write permission for the file, but you must have write permission to the parent directory of this file. That is, even if you do not have a file to write permissions, but you have this file of the parent directory of Write permissions, you can also delete this file, and if there is no write permission to a directory, you will not be able to create files in this directory.
How can you make a directory that allows any user to write to a file without letting the user delete files from someone else in the directory, sticky can play this role. Stciky generally only used in the directory, used in the file does not play any role.
After setting the sticky bit in a directory, (for example,/tmp, the permission is 1777) All users can create files in this directory, but can only delete the files they created, which will protect the user files in the directory that all users can write. (I didn't set the sticky bit in/tmp at that time, but it was set on the file, which is why I set the sticky bit and I can delete the files I created)
　　
--------------------------------------------------------------------------------
　　
Suid/sgid
　　
To understand Suid/sgid, you must first understand process and permission.
We need to know that each process has its effective uid/gid to determine the actual permission it obtains in traditional UNIX filesystem.
Again, the process is generated by binary, and binary is loaded from Shell/shell script execution.
In a normal situation, the effective uid/gid of the process is inherited from the parent, or simply as the uid/gid of the shell.
The Shell's Uid/gid is based on/ETC/PASSWD's 3rd and 42-digit decision.
When we have the above concepts, let's look at the effects of suid on effective Uid/gid:
If binary file with Suid/sgid, its effective ID is not inherited from the parent side, but the binary file itself is the user/group to prevail.
　　
For example, if a prog1 user/group is root, but has no suid/sgid,
That is, when the parent process of a UID (/gid) (500) executes this prog1,
That effective Uid/gid is 500 ...
But if Prog1 set the Suid/sgid, then its effective uid/gid is root!
　　
Once the process effective is root, it has no limitations on the permission of the file system.
That's why I mentioned the Trojan horse program and the virus in the previous example ...
Imagine: If the virus's user/group is set to root and then executed by the general user,
What is the difference between the Suid/sgid and the non-result?
　　
Well, since Suid/sgid has the necessity of existence on the system (as in the case of/USR/BIN/PASSWD and/etc/shadow),
But at the same time there is great damage, in the application to be exceptionally careful!
As a result, bash shell script does not support Suid/sgid on its innate nature.
This is also true for Perl, unless it is installed Suid-perl ....
　　
　　
--------------------------------------------------------------------------------
　　
　　
UID GID Euid Egid
Root 0 0
　　
Test 500 500
　　
Tset.shell 500 500 500 500 after landing the shell
　　
Test.passwd.process 0 Fork
(-r-s--x--x)
　　
Test user fork Binary file passwd, test belongs to others, owns the file x right, because the suid is set, so the fork out of the process (passwd.process) euid=
　　
The UID of the file (passwd) owner is
　　
Passwd.process.euid=passwd.owner.uid=0
　　
Euid and GUIDs are used to process passwd.process to read, write, and execute file shadow when confirming access rights.
　　
　　
-R--------1 root 855 Sep 4 10:58/etc/shadow (Passwd.uid=0 has r privilege)
　　
File Shadow.owner.uid has R permissions for 0 because passwd.process.euid=shadow.ower.uid=0 so the process generated by the test user passwd.process owns the file
　　
R Permissions for Shadow
　　
-r-s--x--x 1 root root 19336 Sep 7 2004/usr/bin/passwd

Liunx UID and GID