Bind Mount 默认覆盖镜像同路径内容，使原文件不可见；通过:ro设为只读可防篡改；结合--user与宿主机权限控制（如chmod 700）可限制访问，路径本身无法隐藏。
bind mount 本身不提供“隐藏宿主机路径”的能力，它只是把宿主机目录映射进容器——路径在容器内是可见、可访问的。所谓“防止容器查看宿主机路径”，准确说是阻止容器看到挂载点原本的镜像内文件内容，同时限制容器对挂载内容的修改权限。这依赖的是 linux 的挂载覆盖（overlay）机制和只读控制，而非真正“隐藏路径字符串”。
理解挂载覆盖行为：宿主机目录会遮盖镜像中同路径内容
当使用 -v /host/dir:/app 启动容器时，如果镜像里原本就有 /app 目录（含文件），那么宿主机的 /host/dir 会完全覆盖掉镜像中的 /app。容器内执行 ls /app 看到的只是宿主机目录里的内容，镜像里原来的东西不可见——这不是加密或屏蔽路径，而是文件系统级的覆盖。
- 这是 Bind Mount 的默认行为，无需额外配置
- 覆盖只发生在挂载点路径层级，不影响容器内其他路径
- 若宿主机目录为空，容器内对应路径也显示为空，不会回退显示镜像内容
用只读挂载（:ro）防止容器篡改或探查宿主机结构
加上 :ro 选项后，容器内对该挂载路径只有读权限，无法执行 touch、rm、mkdir 等写操作，也避免因误写导致宿主机数据异常。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 命令示例：
docker run -v /home/user/config:/etc/myapp:ro nginx - 容器内仍能
cat /etc/myapp/app.conf查看内容，但不能修改 - 对权限敏感的场景（如配置中心、证书目录），只读是基础防护
结合非 root 用户运行，限制挂载内容访问范围
即使挂载了目录，如果容器进程以普通用户（如 --user 1001:1001）运行，且宿主机目录权限未开放给该 UID/GID，那么容器内将因权限不足而无法读取该目录——实现事实上的“不可见”。
- 宿主机上设置：
chown 2000:2000 /host/data && chmod 700 /host/data - 容器启动时指定：
docker run --user 1001:1001 -v /host/data:/data nginx - 此时容器内执行
ls /data会报Permission denied
补充：不要依赖路径名混淆来“隐藏”
有人试图用深层嵌套路径（如 -v /var/log/nginx:/tmp/a/b/c/d）让路径难发现，但这毫无安全意义。容器内通过 mount 或 findmnt 命令可直接列出所有挂载项，路径名本身无法隐藏。
- 验证方式：
docker exec -it mycontainer mount | grep ':/' - 真正有效的控制维度只有三个：是否覆盖、是否只读、是否有访问权限
- 敏感数据不应靠路径隐蔽，而应靠权限隔离 + 最小挂载原则
