摘要：?jiǎn)栴}產(chǎn)生原因最近在使用的時(shí)候經(jīng)常遇到權(quán)限問(wèn)題。如果權(quán)限不夠，就會(huì)出現(xiàn)問(wèn)題。從上圖可以看到，主進(jìn)程的擁有者是，可以讀寫(xiě)任何文件，權(quán)限肯定沒(méi)問(wèn)題。要解決這個(gè)問(wèn)題，其實(shí)就是讓用戶有權(quán)讀寫(xiě)以及其中的文件。

最近在使用docker的時(shí)候經(jīng)常遇到權(quán)限問(wèn)題。
通過(guò)這個(gè)stackoverflow回答，我明白了問(wèn)題出現(xiàn)的主要原因：Docker在進(jìn)行bind mount的時(shí)候，或者在進(jìn)行COPY的時(shí)候，會(huì)保持文件的權(quán)限比特位（比如755）、owner ID（比如1000）、group ID（比如1000）與宿主機(jī)器上的來(lái)源文件相同。而【docker容器主進(jìn)程的owner ID】（比如www-data(33)）往往與【宿主機(jī)器上的文件的owner ID】（比如xiaoming(1000)）不一樣。如果【docker容器主進(jìn)程的owner】沒(méi)有權(quán)限讀/寫(xiě)這個(gè)文件，那么bind-mounts和COPY到容器內(nèi)的文件就不會(huì)產(chǎn)生我們預(yù)想的效果（比如配置文件無(wú)法被容器進(jìn)程讀取、寫(xiě)入）。

如果沒(méi)有時(shí)間查看下面的最佳解決方案，可以試試這個(gè)簡(jiǎn)單粗暴的解決方案：在宿主機(jī)器上，通過(guò)sudo chmod -R 777 /path/to/dir將被掛載的目錄的權(quán)限比特位設(shè)為777。這樣，這個(gè)目錄就能被任何用戶讀寫(xiě)，包括【docker容器主進(jìn)程的owner】。但是這個(gè)方法可能會(huì)造成安全隱患，另外，git會(huì)將權(quán)限改動(dòng)也視為文件變動(dòng)（需要設(shè)置一下git來(lái)解決）。

使用上一篇博客介紹的查看信息命令，在宿主機(jī)器上，檢查被bind-mount或者被COPY的文件的權(quán)限信息：權(quán)限比特位（比如755）、owner ID（比如1000）、group ID（比如1000）。

通過(guò)以下命令，在指定容器內(nèi)運(yùn)行一個(gè)bash：

docker exec -it container_name /bin/bash

進(jìn)入容器的bash以后，你就可以再次使用上一篇博客的查看信息命令，來(lái)查看容器中的進(jìn)程、文件、用戶信息了:

你可以驗(yàn)證一下被bind-mount、COPY的文件，它們的權(quán)限信息是否與宿主上的相同：權(quán)限比特位、owner ID、group ID。

然后，你應(yīng)該通過(guò)ps aux來(lái)查看【容器主進(jìn)程】的owner用戶是誰(shuí)（如果沒(méi)有ps命令的話按照上一篇博客的指示來(lái)安裝），這個(gè)owner就是需要訪問(wèn)文件的用戶，這個(gè)用戶的權(quán)限決定了這個(gè)進(jìn)程是否有權(quán)訪問(wèn)【我們bind-mount、COPY到容器中的文件】。如果權(quán)限不夠，就會(huì)出現(xiàn)問(wèn)題。

從上圖可以看到，主進(jìn)程的擁有者是root，root可以讀寫(xiě)任何文件，權(quán)限肯定沒(méi)問(wèn)題。但是主進(jìn)程還創(chuàng)建了兩個(gè)子進(jìn)程，擁有者是www-data，這個(gè)用戶有可能無(wú)法讀寫(xiě)【被bind-mount或者COPY到容器內(nèi)的文件】！

因此，現(xiàn)在我們需要檢查www-data是否存在權(quán)限不足的問(wèn)題，首先通過(guò)id username來(lái)查看這個(gè)用戶的 user id、primary group id、加入的所有群組 的信息：

然后，使用stat或者ls -na命令，查看【被bind-mount或者COPY到容器內(nèi)的文件】的權(quán)限信息：

上圖的/codeigniter文件夾是我通過(guò)bind-mount掛載到容器內(nèi)的。可以看到這個(gè)文件夾以及其中的文件的ownerId:groupId都是1000:1000，而www-data的ownerId:groupId是33:33。再結(jié)合這些文件的權(quán)限信息（比如-rw-rw-r--、drwx------），www-data只能讀取其中一些文件，無(wú)法寫(xiě)入任何文件，/codeigniter/application/這個(gè)文件夾內(nèi)的內(nèi)容連訪問(wèn)都不行！

如上圖，用stat也能看到同樣的文件信息，只不過(guò)一次只能看到一個(gè)文件或文件夾的信息。

【容器主進(jìn)程】有可能會(huì)創(chuàng)建其他的進(jìn)程一起工作（比如上面的例子），如果是這樣的話，你需要檢查所有子進(jìn)程都有權(quán)訪問(wèn)自己所需的文件。

上面的例子中，/codeigniter以及其中內(nèi)容的權(quán)限比特位、owner ID、group ID都與我的宿主機(jī)器上的codeigniter文件夾相同（我登陸ubuntu的賬戶的userid就是1000）！保持文件的元數(shù)據(jù)(filesystem metadata)是docker的一個(gè)特點(diǎn)，也是一個(gè)坑點(diǎn)。

既然知道了問(wèn)題的成因，那么我們就可以想辦法解決它了。
要解決這個(gè)問(wèn)題，其實(shí)就是讓www-data用戶有權(quán)讀寫(xiě)/codeigniter以及其中的文件。

有兩個(gè)思路：

改變www-data的uid和gid，從33:33變成1000:1000。這樣www-data就是這些文件的owner了，自然就有需要的權(quán)限了。改變uid和gid可以通過(guò)我上篇文章介紹的usermod命令。具體來(lái)說(shuō)，就是在Dockerfile中加入這樣一句：RUN usermod -u 1000 www-data && usermod -G 1000 www-data。（其實(shí)不需要改gid的，改uid就可以成為owner了）

改變?nèi)萜鲀?nèi)/codeigniter的權(quán)限信息，使得www-data(33:33)有權(quán)讀寫(xiě)它：

通過(guò)chmod命令，在宿主機(jī)器上改變codeigniter文件夾的權(quán)限比特為777。這樣，在bind-mount到容器里面以后它的權(quán)限也是777，因此任何用戶都可以讀寫(xiě)它的內(nèi)容。這個(gè)方法要求修改開(kāi)發(fā)環(huán)境，不太優(yōu)雅。

在構(gòu)建image時(shí)，將所有需要的文件COPY到鏡像內(nèi)，然后通過(guò)Run chmod 777 -R /codeigniter使得www-data獲得讀寫(xiě)權(quán)限，或者Run chown www-data:www-data -R /codeigniter使得www-data成為owner。

實(shí)際上COPY --chown=www-data:www-data ./codeigniter /codeigniter/就能一步將【被COPY的文件】的owner設(shè)置為容器內(nèi)的某個(gè)用戶。

我認(rèn)為Run chmod 777 -R /codeigniter這個(gè)解決方案是最方便省事的。

但是我不太想chmod 777，我采用的是COPY --chown=www-data:www-data ./codeigniter /codeigniter/的方案，我喜歡這種方案，因?yàn)樗?strong>只做恰到好處的修改，不多不少。要用好這個(gè)方案，我們需要知道被COPY的文件會(huì)被哪些進(jìn)程訪問(wèn)、這些進(jìn)程的onwer分別是誰(shuí)。

使用這個(gè)方案以后的結(jié)果：


www-data用戶的進(jìn)程可以讀寫(xiě)這些文件了！