下面我们为 /bin/bash 程序设置相关的 capabilities：
$ sudo setcap cap_setgid,cap_setuid+ep /bin/bash
$ 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 中就相当于一个普通的用户。
User namespace 与其它 namespace 的关系
Linux 下的每个 namespace，都有一个 user namespace 与之关联，这个 user namespace 就是创建相应 namespace 时进程所属的 user namespace，相当于每个 namespace 都有一个 owner(user namespace)，这样保证对任何 namespace 的操作都受到 user namespace 权限的控制。这也是为什么在子 user namespace 中设置 hostname 失败的原因，因为要修改的 uts namespace 属于的父 user namespace，而新 user namespace 的进程没有老 user namespace 的任何 capabilities。
