All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Djalal Harouni <tixxdz@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Alexey Gladkov <gladkov.alexey@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Vasiliy Kulikov <segoon@openwall.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Oleg Nesterov <oleg@redhat.com>,
	Pavel Emelyanov <xemul@parallels.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [RFC] Add option to mount only a pids subset
Date: Thu, 09 Mar 2017 14:52:46 -0600	[thread overview]
Message-ID: <877f3ydvfl.fsf@xmission.com> (raw)
In-Reply-To: <CAEiveUczqzHZG7jcM72oWXAKYZSPJ0ywYEXGDV1sn_FAhr28pA@mail.gmail.com> (Djalal Harouni's message of "Thu, 9 Mar 2017 12:26:49 +0100")

Djalal Harouni <tixxdz@gmail.com> writes:

> On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov <gladkov.alexey@gmail.com> wrote:
>> >
>> > After discussion with Oleg Nesterov I reimplement my patch as an additional
>> > option for /proc. This option affects the mountpoint. It means that in one
>> > pid namespace it possible to have both the whole traditional /proc and
>> > /proc with only pids subset.
>> >
>>
>> I like this.  I think you should split it into two patches, though:
>> one that reworks how procfs gets mounted and one that makes adds the
>> new functionality.
>>
>> Djajal had some concerns about the first part breaking applications
>> that use stat and expect certain behavior.  This should be manageable,
>> though, but making stat work appropriately.
>
> I'm bit lost in the two discussion, however the main concern I was
> discussing with Andy was if you have per superblock proc mounts then
> each mount will end up with its own device ID st_dev, right now they
> share the same ID if they are in the same pid namespace, but if we
> change that then we may break the following:
> http://man7.org/linux/man-pages/man7/namespaces.7.html
>
> Both new NS_GET_PARENT and NS_GET_USERNS ioctl() that return an fd,
> suggests to follow up with fstat() to identify the namespaces..
> "By applying fstat(2) to the returned file descriptor, one obtains a
> stat structure whose st_dev (resident device) and st_ino (inode
> number) fields together identify the owning/parent namespace."
>
> Other /proc/self/ns/* comparison and stat() logic...
>
> Andy suggested that we may have the same st_dev for mounts in the same
> pid namespace... I'm not sure which side effect this may bring!

Well right now it is less of an issue than you image.  I suggest you
stat /proc and /proc/self/ns/* and look at st_dev.

That said anything that changes today's proc needs to be tested with a
range of distro's especially those using selinux and apparmor as they
tend to have policies that are very sensitive to the implementation
details.  Such that seemingly innocent changes can cause systems to stop
booting.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Alexey Gladkov
	<gladkov.alexey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Kirill A. Shutemov"
	<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>,
	Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	James Bottomley
	<James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
Subject: Re: [RFC] Add option to mount only a pids subset
Date: Thu, 09 Mar 2017 14:52:46 -0600	[thread overview]
Message-ID: <877f3ydvfl.fsf@xmission.com> (raw)
In-Reply-To: <CAEiveUczqzHZG7jcM72oWXAKYZSPJ0ywYEXGDV1sn_FAhr28pA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Djalal Harouni's message of "Thu, 9 Mar 2017 12:26:49 +0100")

Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>>
>> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov <gladkov.alexey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> > After discussion with Oleg Nesterov I reimplement my patch as an additional
>> > option for /proc. This option affects the mountpoint. It means that in one
>> > pid namespace it possible to have both the whole traditional /proc and
>> > /proc with only pids subset.
>> >
>>
>> I like this.  I think you should split it into two patches, though:
>> one that reworks how procfs gets mounted and one that makes adds the
>> new functionality.
>>
>> Djajal had some concerns about the first part breaking applications
>> that use stat and expect certain behavior.  This should be manageable,
>> though, but making stat work appropriately.
>
> I'm bit lost in the two discussion, however the main concern I was
> discussing with Andy was if you have per superblock proc mounts then
> each mount will end up with its own device ID st_dev, right now they
> share the same ID if they are in the same pid namespace, but if we
> change that then we may break the following:
> http://man7.org/linux/man-pages/man7/namespaces.7.html
>
> Both new NS_GET_PARENT and NS_GET_USERNS ioctl() that return an fd,
> suggests to follow up with fstat() to identify the namespaces..
> "By applying fstat(2) to the returned file descriptor, one obtains a
> stat structure whose st_dev (resident device) and st_ino (inode
> number) fields together identify the owning/parent namespace."
>
> Other /proc/self/ns/* comparison and stat() logic...
>
> Andy suggested that we may have the same st_dev for mounts in the same
> pid namespace... I'm not sure which side effect this may bring!

Well right now it is less of an issue than you image.  I suggest you
stat /proc and /proc/self/ns/* and look at st_dev.

That said anything that changes today's proc needs to be tested with a
range of distro's especially those using selinux and apparmor as they
tend to have policies that are very sensitive to the implementation
details.  Such that seemingly innocent changes can cause systems to stop
booting.

Eric

  reply	other threads:[~2017-03-09 20:57 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-18 22:53 [PATCH] Add pidfs filesystem Alexey Gladkov
2017-02-18 23:34 ` kbuild test robot
2017-02-18 23:34 ` kbuild test robot
2017-02-20  4:05 ` Eric W. Biederman
2017-02-20 10:36   ` Alexey Gladkov
2017-02-22 20:11   ` Richard Weinberger
2017-02-21 14:57 ` Oleg Nesterov
2017-02-22  7:40   ` Pavel Emelyanov
2017-02-22 12:04     ` Alexey Gladkov
2017-02-22 13:08       ` Pavel Emelyanov
2017-02-22 11:53   ` Alexey Gladkov
2017-02-22 15:37   ` Dmitry V. Levin
2017-02-22 17:48     ` Oleg Nesterov
2017-02-22 19:56       ` Alexey Gladkov
2017-03-06 23:05   ` [RFC] Add option to mount only a pids subset Alexey Gladkov
2017-03-06 23:05     ` Alexey Gladkov
2017-03-07 16:24     ` Andy Lutomirski
2017-03-07 16:24       ` Andy Lutomirski
2017-03-09 11:26       ` Djalal Harouni
2017-03-09 20:52         ` Eric W. Biederman [this message]
2017-03-09 20:52           ` Eric W. Biederman
2017-03-11 21:51         ` Alexey Gladkov
2017-03-11 21:51           ` Alexey Gladkov
2017-03-11  0:05       ` Alexey Gladkov
2017-03-11  0:05         ` Alexey Gladkov
2017-03-07 17:49     ` Oleg Nesterov
2017-03-10 23:46       ` Alexey Gladkov
2017-03-10 23:46         ` Alexey Gladkov
2017-03-12  1:54     ` Al Viro
2017-03-12  1:54       ` Al Viro
2017-03-12  2:13       ` Al Viro
2017-03-12  2:13         ` Al Viro
2017-03-13  3:19         ` Andy Lutomirski
2017-03-13  3:19           ` Andy Lutomirski
2017-03-13 13:27           ` Al Viro
2017-03-13 13:27             ` Al Viro
2017-03-13 15:24             ` Andy Lutomirski
2017-03-13 15:24               ` Andy Lutomirski
2017-03-23 15:59               ` [PATCH] proc: allow to change proc mount options per mount Djalal Harouni
2017-03-23 15:59                 ` Djalal Harouni
2017-03-20 12:58         ` [RFC] Add option to mount only a pids subset Alexey Gladkov
2017-03-23 16:05           ` Oleg Nesterov
2017-03-23 16:05             ` Oleg Nesterov
2017-03-23 22:57             ` Alexey Gladkov
2017-03-23 22:57               ` Alexey Gladkov
2017-03-23 16:06           ` Djalal Harouni
2017-03-23 16:06             ` Djalal Harouni
2017-03-23 22:07             ` Alexey Gladkov
2017-03-26  7:03               ` Djalal Harouni
2017-03-26  7:03                 ` Djalal Harouni
2017-03-30 21:45                 ` Alexey Gladkov
2017-03-30 21:45                   ` Alexey Gladkov
2017-02-27 18:56 ` [PATCH] Add pidfs filesystem Michael Kerrisk

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=877f3ydvfl.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=gladkov.alexey@gmail.com \
    --cc=kirill@shutemov.name \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=oleg@redhat.com \
    --cc=segoon@openwall.com \
    --cc=tixxdz@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xemul@parallels.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 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.