We understand from the preceding section that both the shared object that is being worked upon (here, the file myfile) and the process that is performing some access (rwx) on the object (here, the echo process) matter in terms of permissions.

Let's zoom deeper into the process attributes with respect to the permissions model. So far, we have learned that each process is associated with a UID and a GID, thereby allowing the kernel to run its internal algorithms and determine whether access to a resource (or object) should be allowed.

If we look deeper, we find that each process UID is actually not a single integer value, but two values:

• The Real User ID (RUID)
• The Effective User ID (EUID)

Similarly, the group information is not one integer GID value, rather it's two integers:

• The Real Group ID (RGID)
• The Effective Group ID (EGID)

So, with respect to privileges, each process has four integer values associated with it:
{RUID, EUID, RGID, EGID};  these are called the process credentials.

But what exactly do they mean?

Every process has to run under the ownership and group membership of somebody; this somebody is of course the user and group IDs of the person who logs in.

The real IDs are the original values associated with the user who logged in; in effect, they are nothing but the UID:GID pair from the /etc/passwd record for that user. Recall that the id(1) command reveals precisely this information:

$ id
uid=1000(seawolf) gid=1000(seawolf) groups=1000(seawolf),4(adm), [...]
$ 

The uid and gid values displayed are obtained from the /etc/passwd record for seawolf. In reality, the uid/gid values become the running process's RUID/RGID values respectively!

The real numbers reflect who you originally are—your login account information in the form of integer identifiers. Another way to put it: the real numbers reflect who owns the process.

What about the effective values?

The effective values are to inform the OS as to effectively (at this moment) what privileges (user and group) the process is running under. Here are a couple of key points:

• When performing permission checks, the OS uses the process's effective values, not the real (original) values.
• EUID = 0 is what the OS actually checks for to determine whether the process has root privilege.

By default it is as follows:

• The EUID = RUID
• The EGID = RGID

This implies that, for the preceding example, the following is true:

{RUID, EUID, RGID, EGID} = {1000, 1000, 1000, 1000}

Yes. This brings up a question (don't you think?): if the real and effective IDs are the same, then why do we require four numbers at all? Two will do, right?

Well, here's the thing: they usually (by default) are the same, but they can change. Let's see how this can happen.

Before that, though, think about this scenario: a user is logged in, and is on the shell; what are their privileges? Well, just run the id(1) program; the output will display the UID and GID, which we now know is actually {RUID, EUID} and the {RGID, EGID} pair with the same values.

For the sake of an easier-to-read example, let's take the liberty of changing the GID value from 1000, to, say, 2000. So, now, if the values are UID=1000 and GID=2000, and the user now runs, shall we say, the vi editor, now the situation is like this, refer to the given table, process credentials - normal case: