docker 镜像的用户密码的问题？

[rizon]

突然想起这个问题。之所以问这个问题，是因为我最近使用 jupyter 的官方镜像，但是发现登陆的用户不是 root，缺少一些权限。

1. docker 镜像默认是不是没有密码？
2. 那么一些镜像如果用户不是 root 用户该怎么切换用户呢？（只有 使用--user参数这一种方法吗？）
3. 如果我修改了用户的密码，那么 docker 的 exec 命令还可以直接进入到 bash 吗？如果可以想问一下这个 exec 命令是什么原理？为什么不用关心用户权限。

[ipwx]

@zmj1316 然后对于小白用户，你直接给他们做一个巨大的整合的 Docker Image 就好了。。。

[zmj1316]

@ipwx
1. 我这里容器专人专用，谁要用某个环境，我就给他从对应的 image 开一个容器和配套的端口，把他的数据卷挂进去，没有共用的说法。

2. 这些都是一次性的要求，每次有新的环境要求出来，我都单独配好 image，下次谁再要的我就直接从现有的开容器出去了。像 py 版本这样简单的需求，让他自己去容器里面装都没事，反正容器就他自己用，root 自己折腾去😄

[raysonx]

@zmj1316 @rizon 又见 X-Y 问题（ https://coolshell.cn/articles/10804.html ）。。。
用户需要的不是容器本身，而是为了解决某一实际问题，容器只是你为了解决某问题而设想的一种手段。你应该直接说为了解决什么问题，而不是隐藏要解决的问题，自己提出一种方案，然后询问要关于这种方案的问题。

[raysonx]

回到正题：

> docker 镜像默认是不是没有密码？
没有。容器不是虚拟机，只是内核提供的一种资源隔离手段。Docker daemon 本身是以 root 用户运行的，在创建新进程时直接用 setuid 就可以切换为指定的用户。

> 那么一些镜像如果用户不是 root 用户该怎么切换用户呢？（只有 使用--user 参数这一种方法吗？）
对，只有这一种方法。实际用户是由容器启动时决定的而不是镜像构建时决定的，镜像中只是指定了--user 参数的默认值。

> 如果我修改了用户的密码，那么 docker 的 exec 命令还可以直接进入到 bash 吗？如果可以想问一下这个 exec 命令是什么原理？为什么不用关心用户权限。
假设无效，见问题 1 的回答。

[zmj1316]

@raysonx 实践出真知，又不是我设想的，我用了以后的确摆脱了大量的 SA 工作啊。

用户要的就是个能 root 的虚拟机，可是显卡虚拟化太蛋疼了，还要帮用户配环境太蛋疼了，有那个找人问的时间我早已经把问题解决掉了。

[raysonx]

@zmj1316 我不知道你的具体应用场景，所以不扯太多了。总之感觉这种用法是歪路子。。。

[passerbytiny]

@zmj1316 结合你楼下的回复，大致推测你的管理方式：来一个人或任务就给一个容器，搞坏了或者不想用了，容器直接销毁；每个人有一个专门的数据卷。

首先要说明一点，你这种环境，数据卷只起到了外置可共享磁盘的作用，或者就叫做：可挂载的网盘。

你这种方式正好应了我原来的推测： [不会是不挂载数据卷，出问题的时候直接销毁并重建容器吧，相当于“快速重新安装系统”。]

你这种工作，不用 docker，换成 hyper-v、vmware、virtualbox 都能做，而且制作镜像、挂载和管理共享盘、配置网络等等更方便。

[rizon]

@CivAx docker run 指定的用户也是镜像里的用户，我实际测试过，用户‘ games ’在 busybox 镜像里面没有，就无法使用该用户运行镜像


@raysonx 你说的第三条假设无效，我不是很理解。我测试过了，修改了用户密码后，可以正常使用 sudo 和 su 操作了。不过 exec 命令确实可以直接登陆。

[zmj1316]

@passerbytiny 因为这几个虚拟机没有现成的镜像，而 docker 有丰富的 dockerfile 资源，拿来就用，我这人懒🤣。

并且这几个要搞 gpu 虚拟化什么的，配起来很麻烦，不像 nvidia docker 基本无缝。

[raysonx]

@rizon 你的理解是不对的。Docker 默认不启用 user namespace，容器内的用户和主机的用户实际上是相同的。你看到的只是用户名不同，用户名只是一个显示问，那是虚的，实际的 uid 是相同的。假如你在 docker 里以 root 用户运行，他就是真正的 root 用户，只不过 docker 默认 drop 了一些 privilege。假如你挂载一个卷，里面只允许 root 用户读写，则容器里的 root 用户也是可以读写的。
su 要求密码只是 su 自己的逻辑。在 host 上运行 docker exec --user 不需要任何密码。

[raysonx]

继续补充：
su 和 sudo 这种程序是带有 setuid 属性的程序，普通用户执行这个程序会被提权到 root。验证密码只是 su 和 sudo 的内部逻辑。

总之，我想表达的意思是，docker run 或者 docker exec 不需要密码的本质原因是，docker daemon 是以 root 用户运行的，启动 container 的过程就是创建子进程的过程，子进程一开始也会继承 root 用户，接下来会通过 setuid 和 setgid 调用直接切换用户，不需要密码是因为它一开始是 root。这一切过程都和你 image 里的密码什么的无关。

[htfy96]

@zmj1316 这种情况建议使用 lxd，是最佳使用情景。现在 lxd 搞 GPU 虚拟化也非常方便。

[zmj1316]

@htfy96
tensorflow 官方就两种安装方法，pip 和 docker ;
cuda 对 docker 也有官方 dockerfile 支持;
caffe 也有
NV 有完整的 nvidia-docker 支持

所以虽然 LXD 可能是很好，但是对我这种懒人来说，docker 是唯一选择，
因为主要矛盾不在用什么虚拟化这里，而是配环境实在太 TM 麻烦了。。。。。。

[NotNil1]

有了 sudo 和有了 root 有什么区别。。。

[ipwx]

@zmj1316 我也是实践出真知。

我目前的方案是，开放所有计算节点（含 GPU ）的 SSH 登陆，通过编辑 /etc/sudoers 允许用户 sudo docker 和 sudo nvidia-docker。

提供一些整合过的大型 image。

结束。

[ipwx]

@zmj1316 这样的好处有两个：

1、用户不满意我的镜像，可以字节去学 Dockerfile 怎么写呀，或者给我个 PR。 ( https://github.com/haowen-xu/docker-ml-runtime)
2、我们有很多机器。要像你的做法，难道每台机器给每台用户预先都开一个 container 吗？太麻烦了。。。还不如让用户自己解决。
3、我这边机器上有 Mesos 系统，用户可以直接跑 Dockerized Spark。后续正计划写个脚本，用户可以直接提交一个程序，作为 Mesos 任务并使用 Docker 镜像运行。

[ipwx]

@zmj1316 顺便我这边很早就部署了 LDAP 登陆验证，所以每台机器的账号系统是联通的。

[zmj1316]

我这里的用户要求比较挑，他们不希望去了解任何 docker 的东西，要求的就是开箱即用，SSH 连上去，root 耍起来，缺了什么东西装不了的就指挥我去装；

一开始我也是直接几个 image 丢过去，让他们自己启动进去用，一 智障 说接受不了不想学怎么用，直接把整台服务器拔了电给搬自己位子用去了，所以我这操作实属无奈

[zmj1316]

@ipwx 忘记 @ 了，感觉歪楼了，不说了，都是泪啊

[zmj1316]

顺便给 LZ 说一下，你要在 docker 容器里面执行 apt 命令，其实已经是在当虚拟机用了，因为一般 apt 这种操作是在构建镜像的时候用的，你要是缺什么东西，可以写 dockerfile 里，装到镜像里面，然后再启动容器