Skip to content

restore: do mount proc in usernsd on certain conditions #2600

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: criu-dev
Choose a base branch
from
Open

restore: do mount proc in usernsd on certain conditions #2600

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 27 additions & 5 deletions criu/cr-restore.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1445,19 +1445,41 @@ static int __legacy_mount_proc(void)
return fd;
}

static int mount_proc(void)
static int userns_mount_proc(void *arg, int pid, int fd)
{
int fd, ret;
int ret;

if (root_ns_mask == 0)
fd = ret = open("/proc", O_DIRECTORY);
ret = open("/proc", O_DIRECTORY);
else {
if (kdat.has_fsopen)
fd = ret = mount_detached_fs("proc");
ret = mount_detached_fs("proc");
else
fd = ret = __legacy_mount_proc();
ret = __legacy_mount_proc();
}

return ret;
}

static int mount_proc(void)
{
int fd, ret;

/*
* In most cases, self-mounting procfs in the containerized process will work.
* But in the case where the process only has its isolated user namespace
* but shares the mount namespace and pid namespace with the host,
* it won't work due to the lack of privilege to do the proc-mount job.
* A Userns call is needed to deal with such scenerios.
*
* See linux/fs/fsopen.c and linux/fs/proc/root.c for more info.
* */

if ((root_ns_mask & CLONE_NEWUSER) && !(root_ns_mask & CLONE_NEWNS) && !(root_ns_mask & CLONE_NEWPID))
fd = ret = userns_call(userns_mount_proc, UNS_FDOUT, NULL, sizeof(NULL), -1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will it be mounted in the target pid namespace?

Copy link
Author

@ToolmanP ToolmanP Feb 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No i don't think it will be mounted and it's gonna be rejected. I fixed this now. The corner case is only when the user namespace is isolated while keeping both mount namespace and pid namespace be shared with host. If either of two namespaces are isolated, the proc fs will be mounted successfully.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a target workload is restored in just separate userns and pid namespaces, userns_mount_proc will fail, because the current process doesn't have CAP_SYS_ADMIN in the current mount namespace. The only way to workaround that is to mount proc from usernsd, and the userns mount callback has to enter the target pid namespace before mounting proc.

else
fd = ret = userns_mount_proc(NULL, -1, -1);

if (fd >= 0) {
ret = set_proc_fd(fd);
close(fd);
Expand Down
Loading