接前一篇文章：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博客

更多内容请看下回。