无法打开uid_map，以便从具有cap_setuid功能集的应用程序中写入

Question

在玩命名空间(7)的一个例子时，我遇到了一种奇怪的行为。

应用程序是做什么的

应用程序user-ns-ex使用CLONE_NEWUSER调用克隆(2)，从而在新的用户命名空间中创建一个新进程。父进程将一个映射(0 1000 1)写入/proc//uid_map文件，并(通过管道)告诉子进程它可以继续进行。子进程然后执行bash。

我复制了源代码这里。

问题所在

该应用程序打开/proc/uid_map，以便编写，如果我没有设置它，也没有设置它的所有功能。

当我只设置set_capuid、set_capgid和可选的cap_sys_admin时，对cap_sys_admin(2)的调用将失败：

设置上限：

arksnote linux-namespaces   # setcap 'cap_setuid,cap_setgid,cap_sys_admin=epi' ./user-ns-ex
arksnote linux-namespaces   # getcap ./user-ns-ex
./user-ns-ex = cap_setgid,cap_setuid,cap_sys_admin+eip

试着跑：

kamyshev@arksnote ~/workspace/personal/linux-kernel/linux-namespaces  $ ./user-ns-ex -v -U -M '0 1000 1' bash
./user-ns-ex: PID of child created by clone() is 19666
ERROR: open /proc/19666/uid_map: Permission denied
About to exec bash

现在是一个成功的案例：

没有能力：

arksnote linux-namespaces   # setcap '=' ./user-ns-ex
arksnote linux-namespaces   # getcap ./user-ns-ex
./user-ns-ex =

运行正常：

 kamyshev@arksnote ~/workspace/personal/linux-kernel/linux-namespaces  $ ./user-ns-ex -v -U -M '0 1000 1' bash
./user-ns-ex: PID of child created by clone() is 19557
About to exec bash
arksnote linux-namespaces   # exit

我一直试图在手册页中找到原因，并且使用不同的能力，但到目前为止没有运气。最让我困惑的是，应用程序运行的能力更少，而不是更多。

有人能帮我澄清这个问题吗？

Answer 1

研究

我已经找到了原因。在我的研究期间，我发现uid_map文件没有打开，因为它的所有权被更改为root。

没有特权的进程，没有能力：

parent(m): capabilities: '='
parent(m): file /proc/4644/uid_map owner uid: 1000
parent(m): file /proc/4644/uid_map owner gid: 1000

设置了非特权进程、功能(cap_setuid=pe)：

parent(m): capabilities: '= cap_setuid+ep'
parent(m): file /proc/4644/uid_map owner uid: 0
parent(m): file /proc/4644/uid_map owner gid: 0
ERROR: open /proc/4668/uid_map: Permission denied

下面的研究将我引向这个主题：是什么原因导致proc资源被root所拥有？

关于“垃圾”旗的规定

这就是发生的事情：

1)当一个进程不可转储时，它的/proc/<pid>节点被赋予根所有权：

// linux/base.c

struct inode *proc_pid_make_inode(struct super_block * sb, struct task_struct *task)
...
        if (task_dumpable(task)) {
                rcu_read_lock();
                cred = __task_cred(task);
                inode->i_uid = cred->euid;
                inode->i_gid = cred->egid;
                rcu_read_unlock();
        }

2)只有当“可丢弃”属性的值为1 (SUID_DUMP_USER)时，进程才是可丢弃的。见ptrace(2)。

3) prctl(2)进一步澄清了情况：

通常，此标志被设置为1。但是，在以下情况下，它被重置为文件/proc/sys/fs/suid_dumpable中包含的当前值(默认为0)：*进程的有效用户或组ID被更改。*进程的文件系统用户或组ID被更改(请参阅凭据(7))。*该进程执行(execve(2))一个set- user -ID或set- group-ID程序，导致有效用户ID或有效组ID的更改。*该进程执行(execve(2))一个具有文件功能的程序(请参见功能(7))，但只在所获得的允许能力超过该进程已允许的能力时才执行。

因此，我的问题产生于上述最后一条规则：

int commit_creds(struct cred *new)
<...> 
    /* dumpability changes */
    if (!uid_eq(old->euid, new->euid) ||
        !gid_eq(old->egid, new->egid) ||
        !uid_eq(old->fsuid, new->fsuid) ||
        !gid_eq(old->fsgid, new->fsgid) ||
        !cred_cap_issubset(old, new)) {
            if (task->mm)
                    set_dumpable(task->mm, suid_dumpable);

修复

解决这一问题的方法有几种：

1. 全球变化/proc/sys/fs/suid_dumpable

echo 1 > /proc/sys/fs/suid_dumpable

1. 只为进程设置“可丢弃”标志：

prctl(PR_SET_DUMPABLE, 1, 0, 0, 0)