创建容器时能否绑定挂载至父挂载命名空间？

首先咱们拆解下你遇到的两个核心问题：绑定挂载的/usr/lib在容器内看不到内容，以及find命令抛出的"Value too large for defined data type"错误——这俩问题大概率是关联的，下面分点分析原因和解决办法：

1. 先搞懂"Value too large for defined data type"错误 #

这个错误最常见的场景是32位程序尝试访问64位文件系统中的大文件/大inode，或者程序与文件系统的架构不兼容。比如你的主机是64位系统，但拷贝到容器里的Busybox是32位版本，当它去访问64位/usr/lib下的文件时，就会因为数据类型长度不匹配触发这个错误。

验证方法： #

在主机上执行file busybox，查看输出：

• 如果显示32-bit相关字样，说明你用的是32位Busybox，换成64位版本即可解决这个错误。

2. 用户命名空间的ID映射缺失（关键问题） #

你在clone3中使用了CLONE_NEWUSER创建新用户命名空间，但没有设置UID/GID映射。这会导致容器内的进程默认以nobody（UID 65534）身份运行，没有权限读取绑定挂载的/usr/lib目录内容——这就是find看不到/lib下文件的核心原因。

解决办法： #

在子进程（clone后的子进程）中，立即设置UID和GID映射：

// 子进程中，clone成功后、执行后续操作前添加这段代码
// 映射容器内UID 0到主机UID 1000（根据你的主机实际UID调整）
int fd = open("/proc/self/uid_map", O_WRONLY);
if (fd != -1) {
    write(fd, "0 1000 1", 7); // 格式：<容器UID起始> <主机UID起始> <映射数量>
    close(fd);
}

// 同理映射GID
fd = open("/proc/self/gid_map", O_WRONLY);
if (fd != -1) {
    write(fd, "0 1000 1", 7);
    close(fd);
}

• 如果你是以非root用户运行这段代码，需要确保主机内核开启了kernel.unprivileged_userns_clone参数：

  sysctl -w kernel.unprivileged_userns_clone=1
  

• 若以root用户运行，无需额外配置，映射会直接生效。

3. 挂载参数与顺序优化 #

你的绑定挂载操作在pivot_root之前执行，逻辑上没问题，但可以调整挂载参数确保递归挂载：

// 绑定挂载时添加MS_REC参数，确保/usr/lib下的子目录也被正确挂载
mount("/usr/lib", "container/lib", NULL, MS_BIND | MS_REC, NULL);

另外，pivot_root之后重新挂载根目录为只读的操作，不会影响已绑定的/lib挂载点，但可以单独确认/lib的挂载属性（可选）：

// pivot_root之后，可单独设置/lib为只读（可选）
mount(NULL, "/lib", NULL, MS_REMOUNT | MS_RDONLY, NULL);

4. 其他可能性排查 #

• 文件系统特性冲突：如果主机/usr/lib所在的文件系统是btrfs、zfs等带有高级特性的文件系统，可能需要在挂载时添加MS_NOSUID、MS_NODEV等选项，避免容器内进程触发权限或特性不兼容问题。
• SELinux/AppArmor限制：如果主机开启了SELinux或AppArmor，可能会阻止容器访问绑定挂载的目录。可以临时关闭测试（setenforce 0），或者配置相应的规则。

调整后的代码流程总结 #

1. 调用clone3创建带新命名空间的子进程；
2. 子进程中立即设置UID/GID映射；
3. 继续执行rootfs准备（创建目录、挂载tmpfs、拷贝Busybox）；
4. 用MS_BIND | MS_REC绑定挂载/usr/lib；
5. 执行pivot_root、调整根目录属性；
6. 启动Busybox进程。

按照这个流程修改后，绑定挂载的/usr/lib应该能在容器内正常访问，"Value too large..."错误也会随Busybox架构匹配或权限修复而消失。

内容的提问来源于stack exchange，提问作者gudenau