linux - 无法打开uid_map以便从设置了cap_setuid功能的应用程序进行写入

在研究user_namespaces(7)的示例时，我遇到了一种奇怪的行为。

该应用程序做什么

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

我已经复制了源代码here。

问题

如果我没有设置功能或全部功能，则应用程序将打开/proc//uid_map进行编写。

当我只设置set_capuid，set_capgid和可选的cap_sys_admin时，对open(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

我一直在尝试在手册页中找到原因，并尝试使用不同的功能，但到目前为止没有运气。最让我困惑的是，该应用程序运行时功能较少，而运行时功能却不足。

有人可以帮我解决这个问题吗？

最佳答案

这个调查

我找到了原因。在我的reasearch期间，我发现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

以下研究使我想到了这个主题:what causes proc pid resources to become owned by root?

“可倾销”标志的规则

这是发生了什么:

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

// 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)仅当其“dumpable”属性的值为1(SUID_DUMP_USER)时，该过程才可转储。参见ptrace(2)。

3)prctl(2)进一步清除了情况:

因此，我的问题来自上述规则的最后一个:

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);

修正

有多种方法可以解决此问题:

全局更改/proc/sys/fs/suid_dumpable:

echo 1 > /proc/sys/fs/suid_dumpable

仅为过程设置“dumpable”标志:

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

关于linux - 无法打开uid_map以便从设置了cap_setuid功能的应用程序进行写入，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/47296408/