Hi Richard, Sorry for the late reply after dealing with my personal issues.
After reading the code, I find out that when /dev/ppp is opened, the instance is in “unattached” state and `file->private_data` is null correspondingly. After creating a new instance, attaching to a instance or attaching to a channel using ioctl (ppp_unattached_ioctl), the state is changed to “attached” and `file->private_data` becomes valid. My opinion is that only checking capability in `current->nsproxy->net_ns->user_ns` is enough. The reason is that to create a ppp interface or control a ppp interface (in short, to “modify” the network configuration), we should always first create a new instance by opening `/dev/ppp` and attach it to a unit or so. As you mentioned, “an user can create a new user_ns followed by a new net_ns and has CAP_NET_ADMIN”. However, in that case, he can create new units by `ioctl PPPIOCNEWUNIT` but cannot attach to units existing in other net_ns by `ioctl PPPIOCATTACH`, because `ppp_find_unit` can only find unit in the current net_ns. In spite of that, I have to admit that there is risk that lots of ppp devices are created filling all kernel memory. I think this can be avoided by some other methods. You have mentioned in another reply that “the use of nsproxy has to be removed” but I don’t understand the reason. In comparison, I found similar usage of nsproxy in `tun.c`. So could you please give a more detailed explanation? Thanks! > 在 2016年6月19日，18:40，Richard Weinberger <rich...@nod.at> 写道： > > Am 19.06.2016 um 12:36 schrieb Shanker Wang: >> >>> 在 2016年6月19日，12:13，Richard Weinberger <rich...@nod.at> 写道： >>> >>> Am 19.06.2016 um 07:21 schrieb Shanker Wang: >>>> This patch removes the check for CAP_NET_ADMIN in the initial namespace >>>> when opening /dev/open. Instead, CAP_NET_ADMIN is checked in the user >>>> namespace the net namespace was created so that /dev/ppp cat get opened >>>> in a unprivileged container. >>>> >>>> Cc: Hannes Frederic Sowa <han...@stressinduktion.org> >>>> Cc: Richard Weinberger <richard.weinber...@gmail.com> >>>> Cc: Guillaume Nault <g.na...@alphalink.fr> >>>> Cc: Miao Wang <shankerwangm...@gmail.com> >>>> Signed-off-by: Miao Wang <miao.w...@tuna.tsinghua.edu.cn> >>>> --- >>>> drivers/net/ppp/ppp_generic.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c >>>> index f572b31..4b3b2b5 100644 >>>> --- a/drivers/net/ppp/ppp_generic.c >>>> +++ b/drivers/net/ppp/ppp_generic.c >>>> @@ -380,7 +380,7 @@ static int ppp_open(struct inode *inode, struct file >>>> *file) >>>> /* >>>> * This could (should?) be enforced by the permissions on /dev/ppp. >>>> */ >>>> - if (!capable(CAP_NET_ADMIN)) >>>> + if (!ns_capable(current->nsproxy->net_ns->user_ns, CAP_NET_ADMIN)) >>>> return -EPERM; >>> >>> Shouldn't this be a ns_capable(net->user_ns, …? >>> Otherwise an user can create a new user_ns followed by a new net_ns and has >>> CAP_NET_ADMIN. We need to check whether he is allowed in the user_ns of the >>> net_ns which belongs to the ppp net device which you want to open. >> You are totally right. However, I wonder how can i get the “net” struct when >> opening /dev/ppp > > I'm sure you can get it somehow via file->private_data. > > Thanks, > //richard
