在編輯“容器如何工作”愛好者雜志的能力頁面時(shí)，我想試著解釋一下為什么 strace 在 Docker 容器中無法工作。

這里的問題是 —— 如果我在筆記本上的 Docker 容器中運(yùn)行 strace，就會(huì)出現(xiàn)這種情況：

$ docker run  -it ubuntu:18.04 /bin/bash 
$ # ... install strace ... 
[email protected]:/# strace ls 
strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted 

strace 通過 ptrace 系統(tǒng)調(diào)用起作用，所以如果不允許使用 ptrace，它肯定是不能工作的! 這個(gè)問題很容易解決 —— 在我的機(jī)器上，是這樣解決的：

docker run --cap-add=SYS_PTRACE -it ubuntu:18.04 /bin/bash 

但我對(duì)如何修復(fù)它不感興趣，我想知道為什么會(huì)出現(xiàn)這種情況。為什么 strace 不能工作，為什么--cap-add=SYS_PTRACE 可以解決這個(gè)問題?

假設(shè) 1：容器進(jìn)程缺少 CAP_SYS_PTRACE 能力。

我一直以為原因是 Docker 容器進(jìn)程默認(rèn)不具備 CAP_SYS_PTRACE 能力。這和它可以被 --cap-add=SYS_PTRACE 修復(fù)是一回事，是吧?

但這實(shí)際上是不合理的，原因有兩個(gè)。

原因 1：在實(shí)驗(yàn)中，作為一個(gè)普通用戶，我可以對(duì)我的用戶運(yùn)行的任何進(jìn)程進(jìn)行 strace。但如果我檢查我的當(dāng)前進(jìn)程是否有 CAP_SYS_PTRACE 能力，則沒有：

$ getpcaps $$ 
Capabilities for `11589': = 

原因 2：capabilities 的手冊(cè)頁對(duì) CAP_SYS_PTRACE 的介紹是：

CAP_SYS_PTRACE 
       * Trace arbitrary processes using ptrace(2); 

所以，CAP_SYS_PTRACE 的作用是讓你像 root 一樣，可以對(duì)任何用戶擁有的任意進(jìn)程進(jìn)行 ptrace。你不需要用它來對(duì)一個(gè)只是由你的用戶擁有的普通進(jìn)程進(jìn)行 ptrace 。

我用第三種方法測(cè)試了一下(LCTT 譯注：此處可能原文有誤) —— 我用 docker run --cap-add=SYS_PTRACE -it ubuntu:18.04 /bin/bash 運(yùn)行了一個(gè) Docker 容器，去掉了 CAP_SYS_PTRACE 能力，但我仍然可以跟蹤進(jìn)程，雖然我已經(jīng)沒有這個(gè)能力了。什么?為什么?!

假設(shè) 2：關(guān)于用戶命名空間的事情?

我的下一個(gè)(沒有那么充分的依據(jù)的)假設(shè)是“嗯，也許這個(gè)過程是在不同的用戶命名空間里，而 strace 不能工作，因?yàn)槟撤N原因而行不通?”這個(gè)問題其實(shí)并不相關(guān)，但這是我觀察時(shí)想到的。

容器進(jìn)程是否在不同的用戶命名空間中?嗯，在容器中：

root@e27f594da870:/# ls /proc/$$/ns/user -l 
... /proc/1/ns/user -> 'user:[4026531837]' 

在宿主機(jī)：

bork@kiwi:~$ ls /proc/$$/ns/user -l 
... /proc/12177/ns/user -> 'user:[4026531837]' 

因?yàn)橛脩裘臻g ID(4026531837)是相同的，所以容器中的 root 用戶和主機(jī)上的 root 用戶是完全相同的用戶。所以，絕對(duì)沒有理由不能夠?qū)λ鼊?chuàng)建的進(jìn)程進(jìn)行 strace!

這個(gè)假設(shè)并沒有什么意義，但我(之前)沒有意識(shí)到 Docker 容器中的 root 用戶和主機(jī)上的 root 用戶同一個(gè)，所以我覺得這很有意思。

假設(shè) 3：ptrace 系統(tǒng)的調(diào)用被 seccomp-bpf 規(guī)則阻止了

我也知道 Docker 使用 seccomp-bpf 來阻止容器進(jìn)程運(yùn)行許多系統(tǒng)調(diào)用。而 ptrace 在被 Docker 默認(rèn)的 seccomp 配置文件阻止的系統(tǒng)調(diào)用列表中!(實(shí)際上，允許的系統(tǒng)調(diào)用列表是一個(gè)白名單，所以只是ptrace 不在默認(rèn)的白名單中。但得出的結(jié)果是一樣的。)

這很容易解釋為什么 strace 在 Docker 容器中不能工作 —— 如果 ptrace 系統(tǒng)調(diào)用完全被屏蔽了，那么你當(dāng)然不能調(diào)用它，strace 就會(huì)失敗。

讓我們來驗(yàn)證一下這個(gè)假設(shè) —— 如果我們禁用了所有的 seccomp 規(guī)則，strace 能在 Docker 容器中工作嗎?

$ docker run --security-opt seccomp=unconfined -it ubuntu:18.04  /bin/bash 
$ strace ls 
execve("/bin/ls", ["ls"], 0x7ffc69a65580 /* 8 vars */) = 0 
... it works fine ... 

是的，很好用!很好。謎底解開了，除了…..

為什么 --cap-add=SYS_PTRACE 能解決問題?

我們還沒有解釋的是：為什么 --cap-add=SYS_PTRACE 可以解決這個(gè)問題?

docker run 的手冊(cè)頁是這樣解釋 --cap-add 參數(shù)的。

--cap-add=[] 
   Add Linux capabilities 

這跟 seccomp 規(guī)則沒有任何關(guān)系! 怎么回事?

我們來看看 Docker 源碼

當(dāng)文檔沒有幫助的時(shí)候，唯一要做的就是去看源碼。

Go 語言的好處是，因?yàn)橐蕾囮P(guān)系通常是在一個(gè) Go 倉庫里，你可以通過 grep 來找出做某件事的代碼在哪里。所以我克隆了 github.com/moby/moby，然后對(duì)一些東西進(jìn)行 grep，比如 rg CAP_SYS_PTRACE。

我認(rèn)為是這樣的。在 containerd 的 seccomp 實(shí)現(xiàn)中，在 contrib/seccomp/seccomp/seccomp_default.go 中，有一堆代碼來確保如果一個(gè)進(jìn)程有一個(gè)能力，那么它也會(huì)(通過 seccomp 規(guī)則)獲得訪問權(quán)限，以使用與該能力相關(guān)的系統(tǒng)調(diào)用。

case "CAP_SYS_PTRACE": 
       s.Syscalls = append(s.Syscalls, specs.LinuxSyscall{ 
           Names: []string{ 
               "kcmp", 
               "process_vm_readv", 
               "process_vm_writev", 
               "ptrace", 
           }, 
           Action: specs.ActAllow, 
           Args:   []specs.LinuxSeccompArg{}, 
       }) 

在 moby 中的 profile/seccomp/seccomp.go 和 默認(rèn)的 seccomp 配置文件中，也有一些其他的代碼似乎做了一些非常類似的事情，所以有可能就是這個(gè)代碼在做這個(gè)事情。

所以我想我們有答案了!

Docker 中的 --cap-add 做的事情比它說的要多

結(jié)果似乎是，--cap-add 并不像手冊(cè)頁里說的那樣，它更像是 --cap-add-and-also-whiteelist-some-extra-system-calls-if-required。這很有意義! 如果你具有一個(gè)像 --CAP_SYS_PTRACE 這樣的能力，可以讓你使用 process_vm_readv 系統(tǒng)調(diào)用，但是該系統(tǒng)調(diào)用被 seccomp 配置文件阻止了，那對(duì)你沒有什么幫助!

所以當(dāng)你給容器 CAP_SYS_PTRACE 能力時(shí)，允許使用 process_vm_readv 和 ptrace 系統(tǒng)調(diào)用似乎是一個(gè)合理的選擇。

就這樣!

這是個(gè)有趣的小事情，我認(rèn)為這是一個(gè)很好的例子，說明了容器是由許多移動(dòng)的部件組成的，它們以不完全顯而易見的方式一起工作。