A really important point to understand regarding this topic is this: both the shared object that is being worked upon (here, the myfile file) and the process that is performing some access (rwx) on the object (here, the echo process) matter. To be more correct, their attributes with respect to permissions matter. The next discussion will help make this clear.

Let's consider this step by step:

1. A user with the login name seawolf logs in to the system.
2. On success, the system spawns a shell; the user is now at the shell prompt. (Here, we consider the traditional case of logging into a command-line interface (CLI) console, not a GUI environment.)

Every user has a record; it's stored in the /etc/passwd file. Let's grep the file for this user:

$ grep seawolf /etc/passwd
seawolf:x:1000:1000:Seawolf,,,:/home/seawolf:/bin/bash
$ 

Generically, just do this: grep $LOGNAME /etc/passwd

The passwd entry is a row with seven columns that are colon-delimited fields; they are as follows:

username:<passwd>:UID:GID:descriptive_name:home_dir:program

A few fields require some explanation:

• The second field, <passwd>, always shows up as just x on modern Linux systems; this is for security. Even the encrypted password is never displayed (hackers can very possibly break it via a brute-force algorithm; it's in a root-only file called /etc/shadow).
• The third and fourth fields are the User IDentifier (UID) and Group IDentifier (GID) of the user.
• The seventh field is the program to run on successful login; it's usually the shell (as preceding), but it could be anything.

The last point is a key one: the system spawns a shell for the user who logged in. A shell is the user interface (UI) between the human user and the system on the CLI environment. After all, it's a process; on Linux, bash is usually the shell we use. The shell you receive when you login is called your login shell. It's important, because its privileges determine the privileges of all processes it launches—in effect, the privileges you have when working on the system are derived from your login shell.

Let's look up our shell process:

$ ps
  PID  TTY          TIME  CMD
13833 pts/5     00:00:00  bash
30500 pts/5     00:00:00  ps
$ 

There it is; our bash process has a Process Identifier (PID—a unique integer identifying a process) of 13833. Now, the process has other attributes associated with it; for our current purposes, the key ones are the process User Identifier (UID) and the process Group Identifier (GID).

Can one lookup these UID, GID values for a process? Let's try it out with the id(1) command:

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

The id(1) command shows us that the process UID is 1000 and the process GID also happens to be 1000. (The username is seawolf and this user belongs to several groups.) In the previous example, we have logged in as the user seawolf; this fact is reflected by the id command. Note that every process we now run from this shell will inherit the privileges of this user account, that is, it will run with the same UID and GID as the login shell!

You might reasonably ask: where does the process get its UID and GID values from? Well, think about it: we logged in as the user seawolf, and this account's /etc/passwd entry's third and fourth fields are where the process UID and GID come from.

So, every time we run a process from this shell, that process will run with UID 1000 and GID 1000.

We want to understand how exactly the OS checks whether we can perform an operation such as the following:

echo "I can append this string" >> myfile

So, the key question here is: how exactly, at runtime, when the preceding echo process is attempting to write to the myfile file, does the kernel determine whether the write access is allowed. To do this, the OS must determine the following:

• What is the ownership and group membership of the file in question?
• In what access category is the process attempting the access running under (for example, is it U|G|O)?
• For that access category, does the permission bitmask allow access?

To answer the first question: the file's ownership and group membership information (and a lot more regarding the file) is carried as attributes of the key data structure of the filesystem—the information node (inode). The inode data structure is a per-file structure and lives within the kernel (filesystem; it's read into memory when the file is first accessed). User space can of course access this information via system calls. So, the file owner ID is stored in the inode—let's just call it file_UID. Similarly, the file_GID will also be present in the inode object.