C代码工作正常并正确进入命名空间,但Go代码似乎始终从setns
调用返回EINVAL以进入mnt
命名空间。我已经在Go .so
,1.2
和当前提示上尝试了许多排列(包括带有cgo和外部1.3
的嵌入式C代码)。
单步执行gdb
中的代码,可以看出两个序列在setns
中以libc
的方式完全相同(或者在我看来)。
我已经将下面的代码中的问题煮沸了。我做错了什么?
我有一个用于启动快速busybox容器的shell别名:
alias startbb='docker inspect --format "{{ .State.Pid }}" $(docker run -d busybox sleep 1000000)'
运行此操作后,startbb
将启动一个容器并输出它的PID。
lxc-checkconfig
输出:
Found kernel config file /boot/config-3.8.0-44-generic
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: missing
Network namespace: enabled
Multiple /dev/pts instances: enabled
--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled
--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled
uname -a
产生:
Linux gecko 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
以下C代码可以正常工作:
#include <errno.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
main(int argc, char* argv[]) {
int i;
char nspath[1024];
char *namespaces[] = { "ipc", "uts", "net", "pid", "mnt" };
if (geteuid()) { fprintf(stderr, "%s\n", "abort: you want to run this as root"); exit(1); }
if (argc != 2) { fprintf(stderr, "%s\n", "abort: you must provide a PID as the sole argument"); exit(2); }
for (i=0; i<5; i++) {
sprintf(nspath, "/proc/%s/ns/%s", argv[1], namespaces[i]);
int fd = open(nspath, O_RDONLY);
if (setns(fd, 0) == -1) {
fprintf(stderr, "setns on %s namespace failed: %s\n", namespaces[i], strerror(errno));
} else {
fprintf(stdout, "setns on %s namespace succeeded\n", namespaces[i]);
}
close(fd);
}
}
使用gcc -o checkns checkns.c
进行编译后,sudo ./checkns <PID>
的输出为:
setns on ipc namespace succeeded
setns on uts namespace succeeded
setns on net namespace succeeded
setns on pid namespace succeeded
setns on mnt namespace succeeded
相反,以下Go代码(应该是相同的)并不能很好地工作:
package main
import (
"fmt"
"os"
"path/filepath"
"syscall"
)
func main() {
if syscall.Geteuid() != 0 {
fmt.Println("abort: you want to run this as root")
os.Exit(1)
}
if len(os.Args) != 2 {
fmt.Println("abort: you must provide a PID as the sole argument")
os.Exit(2)
}
namespaces := []string{"ipc", "uts", "net", "pid", "mnt"}
for i := range namespaces {
fd, _ := syscall.Open(filepath.Join("/proc", os.Args[1], "ns", namespaces[i]), syscall.O_RDONLY, 0644)
err, _, msg := syscall.RawSyscall(308, uintptr(fd), 0, 0) // 308 == setns
if err != 0 {
fmt.Println("setns on", namespaces[i], "namespace failed:", msg)
} else {
fmt.Println("setns on", namespaces[i], "namespace succeeded")
}
}
}
相反,运行sudo go run main.go <PID>
会产生:
setns on ipc namespace succeeded
setns on uts namespace succeeded
setns on net namespace succeeded
setns on pid namespace succeeded
setns on mnt namespace failed: invalid argument
答案 0 :(得分:5)
(有an issue filed on the Go project)
所以,这个问题的答案是你必须从单线程上下文中调用setns
。这是有道理的,因为setns
应该将当前线程连接到命名空间。由于Go是多线程的,因此您需要在Go运行时线程开始之前进行setns
调用。
我认为这是因为调用syscall.RawSyscall
的线程不是主线程 - 甚至 with runtime.LockOSThread
结果不是你所期望的(即,goroutine是&#34;锁定&#34;到主C线程,因此相当于下面解释的构造函数)。
我在提交问题后得到的回复建议使用&#34; cgo
构造函数&#34;。我找不到任何适当的&#34;有关此&#34;技巧&#34;的文档,但它在Docker / Michael Crosby的nsinit
中使用,即使我逐行检查了该代码,我也没有尝试以这种方式运行它(见下面的挫折)。
&#34;技巧&#34;基本上你可以在启动Go运行时之前让cgo
执行C函数。
要执行此操作,请添加__attribute__((constructor))
宏以装饰要在Go启动之前运行的函数:
/*
__attribute__((constructor)) void init() {
// this code will execute before Go starts up
// in runs in a single-threaded C context
// before Go's threads start running
}
*/
import "C"
使用此作为模板,我修改了checkns.go
,如下所示:
/*
#include <sched.h>
#include <stdio.h>
#include <fcntl.h>
__attribute__((constructor)) void enter_namespace(void) {
setns(open("/proc/<PID>/ns/mnt", O_RDONLY, 0644), 0);
}
*/
import "C"
... rest of file is unchanged ...
此代码有效,但需要对PID
进行硬编码,因为它无法从命令行输入中正确读取,但它说明了这个想法(如果您提供PID
则有效从如上所述的容器开始。)
令人沮丧,因为我想多次调用setns
,但由于此C代码在Go运行时启动之前执行,因此没有Go代码可用。
更新:在内核邮件列表中进行翻转,为记录此内容的会话提供this link。我似乎无法在任何实际发布的联机帮助页中找到它,但这里引用了setns(2)
的补丁,由Eric Biederman证实:
如果,进程可能无法与新的mount命名空间重新关联 它是多线程的。更改mount命名空间需要 调用者同时拥有CAP_SYS_CHROOT和CAP_SYS_ADMIN 功能在自己的用户命名空间和CAP_SYS_ADMIN中 target mount namespace。