1.如果要与文件系统交互，则必须设置UID_MAP和GID_MAP。由于您使用的是chroot（），您几乎肯定会想与文件系统进行交互，因此这是一个明显的摩擦来源。不是不可能的，只是烦人。 2.假设你没有＆＃39; t有cap_setuid / gid（在父用户名命名空间中），这是一个安全的假设，因为否则你会询问＆＃34;未经特权的chroot＆＃34;首先，然后手册页似乎可以说您只能映射自己的UID / GID。这肯定会产生逻辑意义（这个操作的整个点是给你一个＆＃34;集装箱化＆＃34;或非特权的cap_setuid，所以我们需要以某种方式约束它），但它也意味着Stat（2）将撒谎您对任何文件的所有权，您不拥有（UID / GID未映射，所以它被转换为通用＆＃34; Don＆＃39; T知道＆＃34;子名称空间中的值）。 3. SCM_Credentials还将产生未映射的垃圾，因为有许多其他UID / GID相关的接口。如果您想要使用其他用户拥有的任何进程（例如，在角色帐户下运行的守护程序），您基本上可以确认其身份，但它可以确认您的身份（在某些情况下可能就足够）。 4.普遍地修复了上述所有，测试并维护所有内容，可能比在第一位置授予CAP_SYS_CHROOT可能更难。