From: "chouryzhou(周威)" <chouryzhou@tencent.com>
To: Christian Brauner <christian@brauner.io>,
Todd Kjos <tkjos@google.com>, Martijn Coenen <maco@android.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"dave@stgolabs.net" <dave@stgolabs.net>,
"open list:ANDROID DRIVERS" <devel@driverdev.osuosl.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V4] binder: ipc namespace support for android binder
Date: Tue, 13 Nov 2018 08:12:08 +0000 [thread overview]
Message-ID: <5FBCBE569E134E4CA167B91C0A77FD610198F91F70@EXMBX-SZMAIL022.tencent.com> (raw)
> I have not received an answer to my questions in the last version of this patch
> set. Also it would be good if I could be Cc'ed by default. I can't hunt down all
> patches.
> I do not know of any kernel entity, specifically devices, that change namespaces
> on open().
> This seems like an invitation for all kinds of security bugs.
> A device node belongs to one namespace only which is attached to the
> underlying kobject. Opening the device should never change that.
> Please look at how mqueue or shm are doing this. They don't change
> namespaces on open either.
> I have to say that is one of the main reasons why I disagree with that design.
>
>
If we must return the same context when every open in proc, we can only isolate
binder with mnt namespace instead of ipc namespace, what do you think, Todd?
next reply other threads:[~2018-11-13 8:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 8:12 chouryzhou(周威) [this message]
2018-11-13 16:10 ` [PATCH V4] binder: ipc namespace support for android binder Todd Kjos
-- strict thread matches above, loose matches on Subject: below --
2018-11-20 3:56 chouryzhou(周威)
2018-11-12 9:37 chouryzhou(周威)
2018-11-12 16:45 ` Todd Kjos
2018-11-12 19:24 ` Christian Brauner
2018-11-15 22:33 ` Andrew Morton
2018-11-15 22:54 ` gregkh
2018-11-16 19:19 ` Todd Kjos
2018-11-20 0:23 ` Christian Brauner
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=5FBCBE569E134E4CA167B91C0A77FD610198F91F70@EXMBX-SZMAIL022.tencent.com \
--to=chouryzhou@tencent.com \
--cc=akpm@linux-foundation.org \
--cc=arve@android.com \
--cc=christian@brauner.io \
--cc=dave@stgolabs.net \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=tkjos@android.com \
--cc=tkjos@google.com \
/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).