Skip to content
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.

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

运行完系统就出问题了,特来探讨。 #58

Open
dadahua555 opened this issue Sep 29, 2019 · 12 comments
Open

运行完系统就出问题了,特来探讨。 #58

dadahua555 opened this issue Sep 29, 2019 · 12 comments

Comments

@dadahua555
Copy link

  我的环境是Ubuntu18.04,编译的是几天前从这里git** clone的代码。编译之前先git checkout code-3.1的tag上了。一旦运行完mydocker返回后,在终端执行sudo,报错sudo: no tty present and no askpass program specified。/proc目录下,self,network等几个文件夹变成红色,文件名为数字的进程文件夹也不在了。只能用root关机重启才能解决。我猜猜是否没有彻底隔离?但是看不出来问题,希望作者能给我解答。

@dadahua555
Copy link
Author

`ll /proc/self
ls: cannot read symbolic link '/proc/self': No such file or directory
lrwxrwxrwx 1 root root 0 Sep 29 20:09 /proc/self
``
同时df之类的命令也无法执行了。

@dadahua555
Copy link
Author

dadahua555 commented Sep 30, 2019

经过实验,发现仅仅使用
cmd.SysProcAttr = &syscall.SysProcAttr{ Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS | syscall.CLONE_NEWNET | syscall.CLONE_NEWIPC, }
运行shell并不能隔离pid,使用sudo运行编译出来的文件后,进入容器,会发现id是0,然后真的具有root权限。
而使用
cmd.SysProcAttr = &syscall.SysProcAttr{ Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWIPC | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS | syscall.CLONE_NEWUSER, UidMappings: []syscall.SysProcIDMap{ { ContainerID: 0, HostID: 0, Size: 1, }, }, GidMappings: []syscall.SysProcIDMap{ { ContainerID: 0, HostID: 0, Size: 1, }, }, }
问题就解决了,/proc目录没有问题了,容器也没有真正的root权限了。但是为何如此,我还是没弄明白。有人指点一下吗?

@dadahua555
Copy link
Author

dadahua555 commented Oct 8, 2019

内核版本5.0.0-31-generic #33~18.04.1-Ubuntu SMP Tue Oct 1 10:20:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
在代码code-4.1中,为什么在容器中执行mount,显示的还是继承父进程的设备?

@byte-voyager
Copy link

新的内核版本中,使用Mount之前调用下面这行代码

syscall.Mount("", "/", "", syscall.MS_PRIVATE|syscall.MS_REC, "")

@Joey777210
Copy link

您好,@dadahua555 ,我也是在ubuntu18.04上运行代码,遇到了run -d top时后台并没有top的情况,请问您是否有遇到?

@qqzeng
Copy link

qqzeng commented Apr 28, 2020

您好,@dadahua555 ,我也是在ubuntu18.04上运行代码,遇到了run -d top时后台并没有top的情况,请问您是否有遇到?

以非交互式模式下执行 top 命令需要使用 top -b [-n 10],否则top进程会出现 failed tty get 错误。

@yunkai123
Copy link

新的内核版本中,使用Mount之前调用下面这行代码

syscall.Mount("", "/", "", syscall.MS_PRIVATE|syscall.MS_REC, "")

@Baloneo 多谢,加入这行代码确实解决问题了。

但是想咨询下这行代码的含义和具体的作用。是将当前目录挂载到根目录下吗?还是什么意思?

@aiaiai-czh
Copy link

内核版本5.0.0-31-generic #33~18.04.1-Ubuntu SMP Tue Oct 1 10:20:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 在代码code-4.1中,为什么在容器中执行mount,显示的还是继承父进程的设备?

您好,我使用4.15.0-142的内核版本也出现了同样的问题,容器中显示的还是父进程的设备,这应该如何解决

@y00rb
Copy link

y00rb commented Dec 10, 2021

一样也遇到这个问题:在实验了ID Namespace的代码后,执行Mount Namespace中的操作mount -t proc proc /proc后查看, ls /procps -ef结果和书上一样,没有发现异样。但是当重新编译执行后续代码是。出现了和issue作者一样的问题
image
也是在宿主机上执行任何sudo的命名,都会出现sudo: no tty present and no askpass program specified的错误
有那位大神能指点下迷津呢?这是什么问题导致的?

@y00rb
Copy link

y00rb commented Dec 10, 2021

@dadahua555 请问你有调查出是什么原因吗?

@0x2E
Copy link

0x2E commented Feb 16, 2022

但是想咨询下这行代码的含义和具体的作用。是将当前目录挂载到根目录下吗?还是什么意思?

@yunkai123 意思是把所有挂载点的传播类型改为 private,避免本 namespace 中的挂载事件外泄。

@0x2E
Copy link

0x2E commented Feb 16, 2022

@dadahua555 请问你有调查出是什么原因吗?

@y00rb issues/41#issuecomment-478799767 & issues/41#issuecomment-1041294090

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants