The second question posed previously: what access category will it run under? is important to answer.

The access category will be either Owner (U), Group (G), or Other (O); they are mutually exclusive. The algorithm used by the OS to determine the access category is something like this:

if process_UID == file_UID
then
     access_category = U
else if process_GID == file_GID
then
     access_category = G
else
     access_category = O
fi

Actually, it's a bit more complex: a process can belong to several groups simultaneously. So, at permission checking time, the kernel checks all groups; if the process belongs to any one of them, the access category is set to G.

Finally, for that access category, check the permission bitmask (rwx); if the relevant bit is set, the process will be allowed the operation; if not, it won't be. 

Let's take a look at the following command:

$ ls -l myfile
-rw-rw-r-- 1 seawolf seawolf 186 Feb 17 13:15 myfile
$ 

Another way to clarify—the stat(1) command (which of course is a wrapper over the stat(2) system call) show us the inode content of the file myfile, like this:

$ stat myfile 
  File: myfile
  Size: 186           Blocks: 8          IO Block: 4096   regular file
Device: 801h/2049d    Inode: 1182119     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/ seawolf)   Gid: ( 1000/ seawolf)
Access: 2018-02-17 13:15:52.818556856 +0530
Modify: 2018-02-17 13:15:52.818556856 +0530
Change: 2018-02-17 13:15:52.974558288 +0530
 Birth: -
$ 

Clearly, we are highlighting the file_UID == 1000 and file_GID == 1000.

In our echo example, we find that a few scenarios can play out, depending on who logs in, the group membership(s), and the file's permissions.

So, to understand this properly, let's plant a few scenarios (from now on, we shall just refer to the process UID as the UID and the process GID value as the GID, as opposed to process_UID|GID):

• User logs in as seawolf: [UID 1000, GID 1000]
• User logs in as mewolf: [UID 2000, GID 1000]
• User logs in as cato: [UID 3000, GID 3000]
• User logs in as groupy: [UID 4000, GID 3000, GID 2000, GID 1000]

Once logged in, the user attempts this:

echo "I can append this string" >> <path/to/>myfile

What happens? Which will work (permission allowed) and which won't? Run through the previous scenarios with the previous algorithm, to determine the crucial access category, and you will see; the following table summarizes the cases:

The preceding description is still a bit too simplistic, but is a good starting point. In reality, there's a lot more happening under the hood; the following sections shed light on this.

Prior to this, we will take a slight detour: the chmod(1) command (which of course becomes the chmod(2) system call) is used to set permissions on an object. So, if we do this: chmod g-w myfile to remove write permissions from the group category, then the previous table will change (the rows that get G access will now not be allowed to write).