看上去很奇怪呀，明明是文件的所有者，却没有权限向文件中写入内容！其实根本的原因在于当前的 bash 进程没 CAP_SETUID 和 CAP_SETGID 的权限：
下面我们为 /bin/bash 程序设置相关的 capabilities：
| $ sudo setcap cap_setgid,cap_setuid+ep /bin/bash |
然后重新加载 bash，就可以看到相应的 capabilities 了：
现在重新向 map 文件写入映射信息：
| $ echo '0 1000 500' > /proc/3049/uid_map $ echo '0 1000 500' > /proc/3049/gid_map |
这次的写入成功了。后面就不需要我们手动写入映射信息了，所以我们通过下面的命令把 /bin/bash 的 capability 恢复为原来的设置：
| $ sudo setcap cap_setgid,cap_setuid-ep /bin/bash |
第三步，回到第一个 shell 窗口
重新加载 bash，并执行 id 命令：
当前用户已经变成了 root(新的 user namespace 中的 root 用户)。在看看当前 bash 进程具有的 capability：
0000003fffffffff 表示当前运行的 bash 拥有所有的 capability。
第四步，在第一个 shell 窗口中
查看 /root 目录的访问权限：
没权限啊！尝试修改主机的名称：
依然是没有权限啊！看来这个新 user namespace 中的 root 用户在父 user namespace 里面不好使。这也正是 user namespace 所期望达到的效果，当访问其它 user namespace 里的资源时，是以其它 user namespace 中的相应用户的权限来执行的，比如这里 root 对应父 user namespace 的用户是 nick，所以改不了系统的 hostname。
普通用户 nick 没有修改 hostname 的权限，那把默认的 user namespace 中的 root 用户映射为子 user namespace 中的 root 用户后可以修改 hostname 吗？答案是，不行！那是因为不管怎么映射，当用子 user namespace 的用户访问父 user namespace 的资源的时候，它启动的进程的 capability 都为空，所以这里子 user namespace 的 root 用户在父 user namespace 中就相当于一个普通的用户。
