archive mirror
 help / color / mirror / Atom feed
From: Djalal Harouni <>
To: Andy Lutomirski <>
Cc: Linux Kernel Mailing List <>,
	Kees Cook <>,
	Andrew Morton <>,
	Linux FS Devel <>,
	LSM List <>,
	Linux API <>,
	Dongsu Park <>,
	Casey Schaufler <>,
	James Morris <>,
	"Serge E. Hallyn" <>,
	Jeff Layton <>,
	"J. Bruce Fields" <>,
	Alexander Viro <>,
	Alexey Dobriyan <>,
	Ingo Molnar <>,
	"Eric W. Biederman" <>,
Subject: Re: [PATCH RFC v2 4/6] proc: support mounting private procfs instances inside same pid namespace
Date: Tue, 2 May 2017 16:29:57 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Apr 27, 2017 at 12:13 AM, Andy Lutomirski <> wrote:
> On Tue, Apr 25, 2017 at 5:23 AM, Djalal Harouni <> wrote:
>> We have to align procfs and modernize it to have a per mount context
>> where at least the mount option do not propagate to all other mounts,
>> then maybe we can continue to implement new features. One example is to
>> require CAP_SYS_ADMIN in the init user namespace on some /proc/* which are
>> not pids and which are are not virtualized by design, or CAP_NET_ADMIN
>> inside userns on the net bits that are virtualized, etc.
>> These mount options won't propagate to previous mounts, and the system
>> will continue to be usable.
>> Ths patch introduces the new 'limit_pids' mount option as it was also
>> suggesed by Andy Lutomirski [1]. When this option is passed we
>> automatically create a private procfs instance. This is not the default
>> behaviour since we do not want to break userspace and we do not want to
>> provide different devices IDs by default, please see [1] for why.
> I think that calling the option to make a separate instance
> "limit_pids" is extremely counterintuitive.


> My strong preference would be to make proc *always* make a separate
> instance (unless it's a bind mount) and to make it work.  If that
> means fudging stat() output, so be it.

I also agree, but as said if we change stat(), userspace won't be able
to notice if these two proc instances are really separated, the device
ID is the only indication here.


> Failing that, let's come up with some coherent way to make this work.
> "new_instance" or similar would do.  Then make limit_pid cause an
> error unless new_instance is also set.

This is reasonable and it follows devpts filesystem, when
'new_instance' was introduced to gradually switch to private
instances, then it was made default behaviour. We can do the same and
improve the situation bit by bit without breaking anything.

I will prepare a new clean version with "newinstance" and
"pids=ptraceable" requiring it, this way we don't change anything that
is related to current 'hidepid' behaviour. Let me know please if you
don't agree.

Thank you for the feedback!


  reply	other threads:[~2017-05-02 14:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-25 12:23 [PATCH RFC v2 0/6] proc: support private proc instances per pidnamespace Djalal Harouni
2017-04-25 12:23 ` [PATCH RFC v2 1/6] proc: add proc_fs_info struct to store proc information Djalal Harouni
2017-04-25 12:23 ` [PATCH RFC v2 2/6] proc: move /proc/{self|thread-self} dentries to proc_fs_info Djalal Harouni
2017-04-25 12:23 ` [PATCH RFC v2 3/6] proc: add helpers to set and get proc hidepid and gid mount options Djalal Harouni
2017-04-25 12:23 ` [PATCH RFC v2 4/6] proc: support mounting private procfs instances inside same pid namespace Djalal Harouni
2017-04-26 22:13   ` Andy Lutomirski
2017-05-02 14:29     ` Djalal Harouni [this message]
2017-05-02 16:33       ` Andy Lutomirski
     [not found]         ` <>
2017-05-03 15:18           ` Djalal Harouni
     [not found] ` <>
2017-04-25 12:23   ` [PATCH RFC v2 5/6] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option Djalal Harouni
2017-04-26 22:09     ` Andy Lutomirski
     [not found]       ` <>
2017-05-02 14:00         ` Djalal Harouni
2017-04-25 12:23 ` [PATCH RFC v2 6/6] proc: flush task dcache entries from all procfs instances Djalal Harouni

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).