How process ownership and access Permissions are related

In a Unix system, the concept of process ownership and access permissions are fundamental to the way the system manages security and resource allocation. They work in harmony to regulate which users can execute which operations on a given file or process, thereby maintaining the integrity and reliability of the system.

1. Process Ownership: Every process in a Unix system has an associated user, known as the owner. The owner is typically the user who initiated the process, although a process can also be 'owned' by system users like root or other special-purpose accounts. Process ownership is important because it determines the permissions that a process has when accessing files and other resources. For instance, a process owned by a user can only access files that the user has permissions to access.
2. Access Permissions: Unix systems utilize a permission model to control access to files and directories. Each file or directory has three sets of permissions: one for the owner (user), one for the group, and one for others. Each set of permissions indicates whether the associated user or group can read (r), write (w), or execute (x) the file or directory. For example, a file with permissions "rwxr-xr--" can be read, written, and executed by the owner, read and executed by the group, and only read by others.

The interaction between process ownership and access permissions ensures that only authorized processes can perform specific operations on files and directories. For example, a process owned by User A cannot modify a file owned by User B unless the file's permissions allow it.
Additionally, processes in Unix systems also have the ability to change their effective user ID (EUID) and group ID (GID). This feature is utilized to allow processes to temporarily gain additional privileges necessary for a specific task (e.g., accessing system files), then revert back to their original, less-privileged state. This principle, known as "least privilege", further enhances the security of the system by ensuring processes only have the minimum permissions required to function.
In summary, process ownership and access permissions form a security framework that ensures processes can only access and manipulate files and directories within the permissions allocated to them. This robust model ensures system security, data privacy, and operational integrity, making it a fundamental component of the Unix operating system's design.

Every process has an owner and a group. As mentioned previously, when a process tries to access a file or other system resource, the permissions set on that resource are compared against the ownership of the process to determine if access should be permitted. In general, a process is owned by the same entity that owned its parent. A user owns his or her own login shell, and because all commands started interactively are started by the shell, this means that you own any commands you run from a shell.
In particular, remember that the owner of a process consisting of a running program is not the same as the owner of the file that contains the program.
Of course, this is not the whole story. The init process, for example, is owned by root, and every process derives ultimately from init, yet not every child of init is owned by root. In fact, UNIX provides a mechanism for a process to change its ownership.
One important example of changing ownership occurs with the su command. As you know, the su command starts a subshell with root permissions. The shell started by su is owned by root, not by the user who ran the su command.

The distinction between the user who started a process and the owner of the running process is captured in the notion of real and effective user and group ID. The real user or group ID of a process is the ID of the user or group who started that process. The effective user or group ID is the user or group ID that the system uses to evaluate access permissions for that process.