netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>
Cc: "netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	"zbr\@ioremap.net" <zbr@ioremap.net>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"containers\@lists.linux-foundation.org" 
	<containers@lists.linux-foundation.org>
Subject: Re: [PATCH 0/5] RFC: connector: Add network namespace awareness
Date: Mon, 13 Jul 2020 13:39:48 -0500	[thread overview]
Message-ID: <87lfjn9s3v.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <94defa61204731d7dce37edeb98069c8647722c2.camel@alliedtelesis.co.nz> (Matt Bennett's message of "Sun, 5 Jul 2020 22:31:25 +0000")

Matt Bennett <Matt.Bennett@alliedtelesis.co.nz> writes:

> On Thu, 2020-07-02 at 13:59 -0500, Eric W. Biederman wrote:
>> Matt Bennett <matt.bennett@alliedtelesis.co.nz> writes:
>> 
>> > Previously the connector functionality could only be used by processes running in the
>> > default network namespace. This meant that any process that uses the connector functionality
>> > could not operate correctly when run inside a container. This is a draft patch series that
>> > attempts to now allow this functionality outside of the default network namespace.
>> > 
>> > I see this has been discussed previously [1], but am not sure how my changes relate to all
>> > of the topics discussed there and/or if there are any unintended side
>> > effects from my draft
>> 
>> In a quick skim this patchset does not look like it approaches a correct
>> conversion to having code that works in multiple namespaces.
>> 
>> I will take the changes to proc_id_connector for example.
>> You report the values in the callers current namespaces.
>> 
>> Which means an unprivileged user can create a user namespace and get
>> connector to report whichever ids they want to users in another
>> namespace.  AKA lie.
>> 
>> So this appears to make connector completely unreliable.
>> 
>> Eric
>> 
>
> Hi Eric,
>
> Thank you for taking the time to review. I wrote these patches in an
> attempt to show that I was willing to do the work myself rather than
> simply asking for someone else to do it for me. The changes worked for
> my use cases when I tested them, but I expected that some of the
> changes would be incorrect and that I would need some guidance. I can
> spend some time to really dig in and fully understand the changes I am
> trying to make (I have limited kernel development experience) but
> based on the rest of the discussion threads it seems that there is
> likely no appetite to ever support namespaces with the connector.

Good approach to this.

My sense is that there are few enough uses of connector that if don't
mind changing your code so that it works in a container (and the pidfd
support appears to already provide what you need) that is probably the
past of least resistance.

I don't think it maintaining connector support would be much more work
than it is now, if someone went through and did the work to carefully
convert the code.  So if someone really wants to use connector we can
namespace the code.

Otherwise it is probably makes sense to let the few users gradually stop
using connector so the code can eventually be removed.

Please checkout out the pidfd support and tell us how it meets your
needs.  If there is something that connector really does better it would
be good to know.

Thank you,
Eric

      reply	other threads:[~2020-07-13 18:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02  0:26 [PATCH 0/5] RFC: connector: Add network namespace awareness Matt Bennett
2020-07-02  0:26 ` [PATCH 1/5] connector: Use task pid helpers Matt Bennett
2020-07-02  0:26 ` [PATCH 2/5] connector: Use 'current_user_ns' function Matt Bennett
2020-07-02  0:26 ` [PATCH 3/5] connector: Ensure callback entry is released Matt Bennett
2020-07-02  0:26 ` [PATCH 4/5] connector: Prepare for supporting multiple namespaces Matt Bennett
2020-07-02  0:26 ` [PATCH 5/5] connector: Create connector per namespace Matt Bennett
2020-07-02  5:52   ` kernel test robot
2020-07-02  6:40   ` kernel test robot
2020-07-02 14:32   ` [kbuild] " Dan Carpenter
2020-07-02 13:17 ` [PATCH 0/5] RFC: connector: Add network namespace awareness Eric W. Biederman
2020-07-02 19:10   ` Christian Brauner
2020-07-02 22:44     ` Aleksa Sarai
2020-07-05 22:32     ` Matt Bennett
2020-07-13 18:34       ` Eric W. Biederman
2020-07-14  5:03         ` Aleksa Sarai
2020-07-14  5:19           ` Matt Bennett
2020-07-02 18:59 ` Eric W. Biederman
2020-07-05 22:31   ` Matt Bennett
2020-07-13 18:39     ` Eric W. Biederman [this message]

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=87lfjn9s3v.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=Matt.Bennett@alliedtelesis.co.nz \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=zbr@ioremap.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).