Quoting chenhanxiao@xxxxxxxxxxxxxx (chenhanxiao@xxxxxxxxxxxxxx): > Hello, > > How to reproduce: > 1. Prepare a container, enable userns and disable netns > 2. use libvirt-lxc to start a container > 3. libvirt could not mount sysfs then failed to start. > > Then I found that > commit 7dc5dbc879bd0779924b5132a48b731a0bc04a1e says: > "Don't allow mounting sysfs unless the caller has CAP_SYS_ADMIN rights > over the net namespace." > > But why should we check sysfs mouont permission over net namespace? > We've already checked CAP_SYS_ADMIN though. > > What the relationship between sysfs and net namespace, > or this check is a little redundant? It is not redundant. The whole point is that after clone(CLONE_NEWUSER) you get a newly filled set of capabilities. But you should not have privileges over the host's network namesapce. After you unshare a new network namespace, you *should* have privilege over it. So the fact that we've already check CAP_SYS_ADMIN means nothing, because the capabilities need to be targeted. > Any insights on this? > > Thanks, > - Chen > > PS: codes below could be a workaround > > @@ -34,7 +35,8 @@ static struct dentry *sysfs_mount(struct file_system_type *fs_type, > if (!capable(CAP_SYS_ADMIN) && !fs_fully_visible(fs_type)) > return ERR_PTR(-EPERM); > > - if (!kobj_ns_current_may_mount(KOBJ_NS_TYPE_NET)) > + if (current->nsproxy->net_ns != &init_net && > + !kobj_ns_current_may_mount(KOBJ_NS_TYPE_NET)) > return ERR_PTR(-EPERM); > } > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/containers _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
