No, no, no & no:
I will explain for uid ( it is same for gid) A process can move ID between effective, real, and other. A process can also arbitrarily set an ID if and only if it has capability CAP_SETUID.
Let us look at the way UID and GID are implemented:
There are both numbers stored in a database table (A file), both of these tables are independent. I have a UID, and a primary GID. Both called richard, but with different numbers. The only connections are: in /etc/passwd it lists username, UID, and primary GID. In /etc/group it lists groupname, GID, UIDs.
Most of the time these relationships are not checked, except: at login and when setgid is called (I think).
For efficiency only what is necessary is checked.
- A process can move ID between effective, real, and other (file, saved).
- A process can also arbitrarily set an ID if and only if it has capability CAP_SETUID.
--
From the man page for setreuid(),
setreuid() sets real and effective user IDs of the calling process.
Supplying a value of -1 for either the real or effective user ID forces the system to leave that ID unchanged.
Unprivileged processes may only set the effective user ID to the real user ID, the effective user ID, or the saved set-user-ID.
Unprivileged users may only set the real user ID to the real user ID or the effective user ID.
If the real user ID is set or the effective user ID is set to a value not equal to the previous real user ID, the saved set-user-ID will be set to the new effective user ID.
Completely analogously, setregid() sets real and effective group ID's of the calling process, and all of the above holds with "group" instead of "user".