Step by step learning linux operating system: 10 process data structure II

task_ Source location of struct:

Operation statistics

Including user / kernel running time, up / down switching times, startup time, etc;

u64        utime;//CPU time consumed in user mode
u64        stime;//CPU time consumed by kernel state
unsigned long      nvcsw;//Count of voluntary context switches
unsigned long      nivcsw;//Count of involuntarily context switches
u64        start_time;//Process start time, excluding sleep time
u64        real_start_time;//Process start time, including sleep time

Process kinship

task_ The field about process affinity in struct

struct task_struct __rcu *real_parent; /* real parent process */
struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */
struct list_head children;      /* list of my children */
struct list_head sibling;       /* linkage in my parent's children list */

  • Parent points to its parent process. When it terminates, it must signal its parent process.
  • children represents the head of the list. All elements in the list are its subprocesses.
  • Sibling is used to insert the current process into the sibling list.

real_parent and parent are usually the same; but when debugging programs with GDB in bash, GDB is parent, bash is real_parent

Process permissions

task_ The fields of process permission in struct

/* Objective and real subjective task credentials (COW): */
const struct cred __rcu         *real_cred;
/* Effective (overridable) subjective task credentials (COW): */
const struct cred __rcu         *cred;

real_cred pointer (who can operate my process); cred pointer (who can operate my process)

cred structure

Location / include/linux/cred.h

struct cred {
	atomic_t	usage;
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
	unsigned	securebits;	/* SUID-less security management */
	kernel_cap_t	cap_inheritable; /* caps our children can inherit */
	kernel_cap_t	cap_permitted;	/* caps we're permitted */
	kernel_cap_t	cap_effective;	/* caps we can actually use */
	kernel_cap_t	cap_bset;	/* capability bounding set */
	kernel_cap_t	cap_ambient;	/* Ambient capability set */
	unsigned char	jit_keyring;	/* default keyring to attach requested
					 * keys to */
	struct key __rcu *session_keyring; /* keyring inherited over fork */
	struct key	*process_keyring; /* keyring private to this process */
	struct key	*thread_keyring; /* keyring private to this thread */
	struct key	*request_key_auth; /* assumed request_key authority */
	void		*security;	/* subjective LSM security */
	struct user_struct *user;	/* real user ID subscription */
	struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
	struct group_info *group_info;	/* supplementary groups for euid/fsgid */
	struct rcu_head	rcu;		/* RCU deletion hook */
} __randomize_layout;


RCU (read copy update) is an important synchronization mechanism in Linux. As the name implies, "read, copy and update", and then "read at will, but when updating data, you need to copy a copy first, complete the modification on the copy, and then replace the old data at one time". This is a synchronization mechanism for "read more, write less" shared data implemented by Linux kernel.

Four id groups

  • uid and gid
    The comment is real user/group id
    In general, the ID of the process started by the user is the ID of the user
    When the authority is audited, the two are often not compared
  • euid and egid
    The comment is effective user/group id
    According to which user audit authority
    Operate message queue, shared memory, semaphore and other objects
  • fsuid and fsgid
    The comment is VFS filesystem user/group id
    Permission to audit file operations.
  • suid and sgid
    saved uid and save gid
    Because the original user id is saved by suid and sgid, setuid can be used at any time to change permissions by setting uid or suid.

Generally speaking, fsuid, euid, and uid are the same, as are fsgid, egid, and gid

Special circumstances

  1. User A wants to play the game installed by B
    The permissions of this program file of the game are RWX – r –. A does not have permission to run this program. User B should give user a permission
  2. After opening the permission, A can run the game, but can't save it
    When the game is running, the uid, euid and fsuid of the game process are all user A
    The permission to save this file rw-r – R -- only gives user B write permission, so A can't write it in
  3. Through the chmod u+s program command, set the identification bit of set user ID, and change the game permission to rwsr-xr-x
    When user a starts the game again, the process uid is still user A. because of the set user ID identifier, euid and fsuid are not user a but the owner's ID of the file, that is, both euid and fsuid are changed to user B

capabilities mechanism

In addition to controlling permissions by users and user groups, another mechanism of Linux is capabilities, which uses bitmaps to represent permissions
capability mechanism, which gives some high permissions to ordinary users with fine granularity

Location: include\uapi\linux\capability.h

#define CAP_CHOWN            0
#define CAP_KILL             5
#define CAP_NET_RAW          13
#define CAP_SYS_MODULE       16
#define CAP_SYS_RAWIO        17
#define CAP_SYS_BOOT         22
#define CAP_SYS_TIME         25
#define CAP_AUDIT_READ          37

  • cap_ Allowed indicates the permission that the process can use. But what really works is cap_effective.
  • cap_effective authority, cap_ Allowed range can be greater than cap_effective
  • cap_inheritable indicates that the permission can be inherited. When exec is executed, it inherits the inheritable permission set of the caller and joins the permitted set. However, when exec is executed under a non root user, the inheritable set will not be preserved
  • cap_ Permission allowed to be reserved for all processes in bset system. If there is no permission in this collection, all processes in the system do not have this permission
  • cap_ambient when exec is executed, cap_ambient will be added to cap_ Set to cap at the same time_ In effective, it solves the problem of how to keep the permission when the non root user process uses exec to execute a program

memory management

Data structure mm_struct

struct mm_struct                *mm;
struct mm_struct                *active_mm;

File and file system

Each process has a file system data structure and an open file data structure

/* Filesystem information: */
struct fs_struct                *fs;
/* Open file information: */
struct files_struct             *files;

task_struct data structure

reference material:

Interesting Linux operating system (geek time) link:
Welcome to exchange and study together

Tags: Linux less

Posted on Thu, 25 Jun 2020 00:28:10 -0400 by mjurmann