Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
diff betn "real and effective" user ids & group ids
- Thread starter iaindian
- Start date
The OS operates principly on the numeric values supplied as user id numbers on login. Basically, real and effective user ids permit can one user to "masquerade" as another.
From Bach's "Design of the Unix Operating System",
"The real user id identifies the user who is responsible for the current running process. The effective user id is used to assign ownership of newly created files, check file access permissions, ... signals ..."
Probably the best example is use of /usr/bin/passwd and /etc/passwd to change your password. If you look at the file permissions of /usr/bin/passwd, it has an "s" in the owner execute position, indicating it is a setuserid program. It also has world and group execute privledges. If you look at /etc/passwd, it has only read priviedges.
You might ask, "How does a common user employ a root-owned executable to write to a file with only read permissions?"
To cut to the chase, ...when any user on the OS executes this /usr/bin/passwd, because of the permission settings, it permits the common user to act as root for the express purpose of updating his/her password (only).
There are various API calls to get/set these in the various Unixes: getuid, geteuid, getgid, getegid, etc.
The concept is similar for group ids. I "believe" the book I learned this from was "Unix Security", by Morris, but it is rather dated.
Hope this helps,
Hutch
From Bach's "Design of the Unix Operating System",
"The real user id identifies the user who is responsible for the current running process. The effective user id is used to assign ownership of newly created files, check file access permissions, ... signals ..."
Probably the best example is use of /usr/bin/passwd and /etc/passwd to change your password. If you look at the file permissions of /usr/bin/passwd, it has an "s" in the owner execute position, indicating it is a setuserid program. It also has world and group execute privledges. If you look at /etc/passwd, it has only read priviedges.
You might ask, "How does a common user employ a root-owned executable to write to a file with only read permissions?"
To cut to the chase, ...when any user on the OS executes this /usr/bin/passwd, because of the permission settings, it permits the common user to act as root for the express purpose of updating his/her password (only).
There are various API calls to get/set these in the various Unixes: getuid, geteuid, getgid, getegid, etc.
The concept is similar for group ids. I "believe" the book I learned this from was "Unix Security", by Morris, but it is rather dated.
Hope this helps,
Hutch
- Status