接前一篇文章：Linux內核進程管理子系統有什么第三十九回 —— 進程主結構詳解（35）

本文內容參考：

Linux內核進程管理專題報告_linux rseq-CSDN博客

《趣談Linux操作系統 核心原理篇：第三部分 進程管理》—— 劉超

《圖解Linux內核?基于6.x》 —— 姜亞華 機械工業出版社

特此致謝！

進程管理核心結構 —— task_struct

8. 進程權限相關成員

進程權限相關成員包括以下幾個：

	/* Process credentials: *//* Tracer's credentials at attach: */const struct cred __rcu		*ptracer_cred;/* Objective and real subjective task credentials (COW): */const struct cred __rcu		*real_cred;/* Effective (overridable) subjective task credentials (COW): */const struct cred __rcu		*cred;

這幾個字段的描述如下：

上一回開始對于struct cred進行解析，本回繼續。為了便于理解和回顧，再次貼出struct cred的定義，在include/linux/cred.h中，如下：

/** The security context of a task** The parts of the context break down into two categories:**  (1) The objective context of a task.  These parts are used when some other*	task is attempting to affect this one.**  (2) The subjective context.  These details are used when the task is acting*	upon another object, be that a file, a task, a key or whatever.** Note that some members of this structure belong to both categories - the* LSM security pointer for instance.** A task has two security pointers.  task->real_cred points to the objective* context that defines that task's actual details.  The objective part of this* context is used whenever that task is acted upon.** task->cred points to the subjective context that defines the details of how* that task is going to act upon another object.  This may be overridden* temporarily to point to another security context, but normally points to the* same context as task->real_cred.*/
struct cred {atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALSatomic_t	subscribers;	/* number of processes subscribed */void		*put_addr;unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endifkuid_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 */
#ifdef CONFIG_KEYSunsigned char	jit_keyring;	/* default keyring to attach requested* keys to */struct key	*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 */
#endif
#ifdef CONFIG_SECURITYvoid		*security;	/* LSM security */
#endifstruct user_struct *user;	/* real user ID subscription */struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */struct ucounts *ucounts;struct group_info *group_info;	/* supplementary groups for euid/fsgid *//* RCU deletion */union {int non_rcu;			/* Can we skip RCU deletion? */struct rcu_head	rcu;		/* RCU deletion hook */};
} __randomize_layout;

上一回講到struct cred中的3組字段：

一般來說，fsuid、euid與uid是一樣的；fsgid、egid與gid也是一樣的。因為誰啟動的進程，就應該審核啟動者有沒有相關權限。但是也存在特殊情況。例如：

用戶張三（zhangsan）想運行一個用戶李四（lisi）安裝的應用程序（比如游戲、視頻播放器等）。由于是李四安裝的，當然該應用程序文件的權限是rwxr--r--。也就是說文件屬主（即文件所有者李四）權限為可讀、可寫、可執行；而屬組（同組用戶）權限為只可讀；組外（其他用戶）權限也是只可讀。

那么問題來了，張三想運行該程序，但沒有可執行權限，該怎么辦呢？需要向用戶李四要授權。李四并無意見，于是將應用程序文件的權限由rwxr--r--改為rwxr-xr-x。也就是分別給屬組和組外權限加入了可執行。這樣，張三就可以正常運行程序了。

接下來問題又來了，張三看著看著視頻覺得不錯，想把這個視頻存下來；或者玩游戲過了幾關，想保存進度。一點下載或保存按鈕，壞了，提示無權限。為什么會這樣？因為下載視頻需要有保存路徑的寫入權限，游戲玩家數據是保存在某個文件中的，也需要寫入權限。由于該文件只給所有者李四開了寫入權限，而進程的euid和fsuid都是張三，那當然寫不了了。

又該怎么解決這個問題呢？可以通過chmod u+s xxx命令，給這個應用程序設置set-user-id，將它的權限變為rwsr-xr-x。此時，張三再啟動這個應用的時候，創建的進程uid還是張三（zhangsan），但是euid和fsuid就不是張三了，而是李四（lisi）。也就是說，因為看到了set-user-id標識，euid和fsuid就改為文件所有者即李四了。

關于chmod u+s命令，詳情參考以下文章：

Linux命令 chmod 例：chmod u+s-CSDN博客

更多內容請看下回。