这问题问得好，这是用户命名空间和文件能力搭配时的常见坑，我来给你拆解清楚：

1. 用户命名空间的能力隔离本质 #

用户命名空间最核心的特性就是权限隔离：当你创建一个非初始用户命名空间时，里面的root（UID 0）对应的主机系统身份其实是你的普通用户（比如UID 1000）。文件能力（比如CAP_NET_RAW）的生效逻辑，默认是绑定主机命名空间的权限上下文的——也就是说，这个能力是给主机上有对应权限的用户用的，而用户命名空间里的进程，在主机层面只是普通用户，自然没法直接获取这个能力。

2. 文件能力在用户命名空间的生效限制 #

文件能力分三个核心集合：permitted、effective、inheritable。对于没设setuid位的程序，要让它的文件能力在用户命名空间内生效，必须满足两个关键条件：

• 你在用户命名空间内是以root身份运行程序（只有命名空间内的root才有资格提升权限）；
• 你创建用户命名空间时，必须显式允许CAP_NET_RAW被带入该命名空间。默认情况下，非初始用户命名空间只会被授予少数基础能力（比如CAP_CHOWN、CAP_SETUID），像CAP_NET_RAW这类网络相关的能力不在默认列表里。

举个直观的例子：你用unshare -U ping google.com创建命名空间并运行ping，此时命名空间没被授予CAP_NET_RAW，所以即使ping本身带了这个文件能力，进程也没法获取对应的权限，自然执行失败。

3. 验证与解决方法 #

先验证当前状态 #

• 检查ping的文件能力：运行getcap /usr/bin/ping，正常应该输出/usr/bin/ping cap_net_raw=ep（e代表effective，p代表permitted）。
• 在用户命名空间内检查进程能力：运行capsh --print，你会发现CAP_NET_RAW不在Current:或Bounding set:的能力列表里。

解决办法 #

• 创建命名空间时显式添加能力：用unshare -U --cap-add=CAP_NET_RAW ping google.com，这样在创建用户命名空间时就把CAP_NET_RAW加入允许的能力集合，ping就能正常工作了。
• 容器环境下的配置：如果你用Docker之类的容器，需要在启动时添加对应能力，比如docker run --cap-add=NET_RAW alpine ping google.com。
• 通过ambient能力传递（进阶）：如果需要让子进程也继承这个能力，可以先在命名空间内把CAP_NET_RAW加入ambient集合，不过这个需要系统支持CAP_AUDIT_WRITE和ambient能力特性，操作步骤相对复杂一些。

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