netdev - Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Oct 2013 12:53:11 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	nicolas.dichtel@...nd.com
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	David Miller <davem@...emloft.net>, yamato@...hat.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)

Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:

> Le 15/10/2013 22:34, Eric W. Biederman a écrit :

>> For IFLA_NET_NS_FD not that I know of.
>>
>> Mostly it is doable but there are some silly cases.
>> - Do we need to actually implement SCM_RIGHTS to prevent people
>>    accepting file-descriptors unknowingly and hitting their file
>>    descriptor limits.
>>
>>    In which case we need to call the attribute IFLA_NET_NS_SCM_FD
>>    so we knew it was just an index into the passed file descriptors.n
>>
>> - Do we need an extra permission check to prevent keeping a network
>>    namespace alive longer than necessary?  Aka there are some permission
>>    checks opening and bind mounting /proc/<pid>/ns/net do we need
>>    a similar check.  Perhaps we would need to require CAP_NET_ADMIN over
>>    the target network namespace.
>>
>> Beyond that it is just the logistics to open what is essentially
>> /proc/<pid>/ns/net and add it to the file descriptor table of the
>> requesting process.  Exactly which mount of proc we are going to
>> find the appropriate file to open I don't know.
>>
>> It isn't likely to be lots of code but it is code that the necessary
>> infrastructure is not in place for, and a bunch of moderately hairy
>> corner cases to deal with.
> Got it. This doesn't seems the simpliest/best way to resolve this pb.
> Can we not introduce another identifier (something like IFLA_NET_NS_ID),
> which will not have such constraint?
> inode is unique on the system, why not using it as an opaque value to
> identitfy the netns (like 'ip netns identify' do)?

The age old question why can't we have global identifiers for
namespaces?

The answer is that I don't want to implement a namespace for namespaces.

While the proc inode does work today across different mounts of proc, I
reserve the right at some future date (if it solves a technical problem)
to give each namespace a different inode number in each different mount
of proc.  So the inode number is not quite the unique identifier you
want.  The inode number is a close as I am willing to get to a namespace
of namespaces.

I think the simplest solution is to just not worry about which namespace
the other half of a veth pair is in.  But I have not encountered the
problem where I need to know exactly which namespace we are worrying
about.

Global identifiers are easy until you hit the cases where they make
things impossible.

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html