From: ebiederm@xmission.com (Eric W. Biederman)
To: Gao feng <gaofeng@cn.fujitsu.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH RESEND 1/2] neigh: only allow init_net to change the default neigh_parms
Date: Wed, 12 Jun 2013 18:27:19 -0700 [thread overview]
Message-ID: <87k3lypzpk.fsf@xmission.com> (raw)
In-Reply-To: <51B91DC0.4010707@cn.fujitsu.com> (Gao feng's message of "Thu, 13 Jun 2013 09:17:52 +0800")
Gao feng <gaofeng@cn.fujitsu.com> writes:
> On 06/12/2013 03:33 PM, Eric W. Biederman wrote:
>> Gao feng <gaofeng@cn.fujitsu.com> writes:
>>
>>> Though we don't export the /proc/sys/net/ipv[4,6]/neigh/default/
>>> directory to the un-init_net, but we can still use cmd such as
>>> "ip ntable change name arp_cache locktime 129" to change the locktime
>>> of default neigh_parms.
>>>
>>> This patch disallows the un-init_net to find out the neigh_table.parms.
>>> So the un-init_net will failed to influence the init_net.
>>
>> Interesting...
>>
>> The problem these two patches seek to address seems legit.
>>
>> However I disagree with the way you are handling this.
>>
>> Outside of the initial network namespace we should return -ENOENT
>> instead of -EPERM. Which would match how we handle sysctls, and I think
>> missing neigh table values. Just not making these global values visible
>> seems wise.
>>
>
> Ok, it seems more reasonable.
>
>> The alternative is to use the proper permission test which is
>> capable(CAP_SYS_ADMIN) (instead of testing network namespaces) and
>> return -EPERM if that fails. Which would allow processes in other
>> network namespaces to change the value if they could otherwise change
>> the value.
>>
>
> So you mean the uninitial net namespace can't see these values but it
> can change them? it's too strange.
Sorry I was saying that if you don't want to hide the values the
permissions and (-EPERM) should track the user namespace not the network
namespace.
> And the thresh/interval are both under default/ too, if we return -ENOENT
> for other items, we should also return -ENOENT for them instead of the
> -EPERM.
Yes. Let's return hide the global values and just return -ENOENT for
everything. That seems simplest.
Eric
next prev parent reply other threads:[~2013-06-13 1:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 4:44 [PATCH RESEND 1/2] neigh: only allow init_net to change the default neigh_parms Gao feng
2013-06-12 4:44 ` [PATCH RESEND 2/2] neigh: disallow un-init_net to change thresh of neigh Gao feng
2013-06-12 7:33 ` [PATCH RESEND 1/2] neigh: only allow init_net to change the default neigh_parms Eric W. Biederman
2013-06-13 1:17 ` Gao feng
2013-06-13 1:27 ` Eric W. Biederman [this message]
2013-06-13 3:44 ` Gao feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k3lypzpk.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=davem@davemloft.net \
--cc=gaofeng@cn.fujitsu.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.