From: luto@amacapital.net (Andy Lutomirski)
To: linux-security-module@vger.kernel.org
Subject: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace
Date: Thu, 30 Mar 2017 12:12:31 -0700 [thread overview]
Message-ID: <CALCETrWooKTtViVh4ik9e-3nLs3NET9wptgxhjS9V499sfUJQA@mail.gmail.com> (raw)
In-Reply-To: <1490887379-25880-1-git-send-email-tixxdz@gmail.com>
On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
> Hi,
>
> This RFC can be applied on top of Linus' tree 89970a04d7
>
> This RFC implements support for multiple separate proc instances inside
> the same pid namespace. This allows to solve lot of problems that
> today's use case face.
>
> Historically procfs was tied to pid namespaces, and mount options were
> propagated to all other procfs instances in the same pid namespace. This
> solved several use cases in that time. However today we face new
> problems, there are mutliple container implementations there, some of
> them want to hide pid entries, others want to hide non-pid entries,
> others want to have sysctlfs, others want to share pid namespace with
> private procfs mounts. All these with current implementation won't work
> since all options will be propagated to all procfs mounts.
>
> This series allow to have new instances of procfs per pid namespace where
> each instance can have its own mount option inside the same pid namespace.
> This was also suggested by Andy Lutomirski.
>
>
> Now:
> $ sudo mount -t proc -o unshare,hidepid=2 none /test
>
> The option 'unshare' will allow to mount a new instance of procfs inside
> the same pid namespace.
>
> Before:
> $ stat /proc/slabinfo
>
> File: ?/proc/slabinfo?
> Size: 0 Blocks: 0 IO Block: 1024 regular empty file
> Device: 4h/4d Inode: 4026532046 Links: 1
>
> $ stat /test3/slabinfo
>
> File: ?/test3/slabinfo?
> Size: 0 Blocks: 0 IO Block: 1024 regular empty file
> Device: 4h/4d Inode: 4026532046 Links: 1
>
>
> After:
> $ stat /proc/slabinfo
>
> File: ?/proc/slabinfo?
> Size: 0 Blocks: 0 IO Block: 1024 regular empty file
> Device: 4h/4d Inode: 4026532046 Links: 1
>
> $ stat /test3/slabinfo
>
> File: ?/test3/slabinfo?
> Size: 0 Blocks: 0 IO Block: 1024 regular empty file
> Device: 31h/49d Inode: 4026532046 Links: 1
>
>
> Any better name for the option 'unshare' ? suggestions ?
>
> I was going to use 'version=2' but then this may sound more like a
> proc2 fs which currently impossible to implement since it will share
> locks with the old proc.
>
>
> Al, Eric any comments please ?
I like the concept, except that I think it would be nice to avoid
needing 'unshare', perhaps by making unsharing the default and making
hidepid work backwards compatibly if needed.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-03-30 19:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 15:22 [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace Djalal Harouni
2017-03-30 15:22 ` [PATCH RFC 1/4] proc: add proc_fs_info struct to store proc options Djalal Harouni
2017-03-30 19:10 ` Andy Lutomirski
2017-03-31 10:49 ` Djalal Harouni
2017-03-30 15:22 ` [PATCH RFC 2/4] proc: add helpers to set/get hidepid and gid mount options Djalal Harouni
2017-03-30 15:22 ` [PATCH RFC 3/4] proc: support mounting new procfs instances inside same pid namespace Djalal Harouni
2017-03-30 19:10 ` Andy Lutomirski
2017-03-30 15:22 ` [PATCH RFC 4/4] proc: support flushing dcache entries of a task on multiple procfs mounts Djalal Harouni
2017-03-30 19:12 ` Andy Lutomirski [this message]
2017-03-31 11:45 ` [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace Djalal Harouni
2017-03-30 22:16 ` Alexey Gladkov
2017-03-31 11:26 ` 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:
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=CALCETrWooKTtViVh4ik9e-3nLs3NET9wptgxhjS9V499sfUJQA@mail.gmail.com \
--to=luto@amacapital.net \
--cc=linux-security-module@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 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).