From: 曹树烽 <caosf.fnst-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
To: Aleksa Sarai <asarai-l3A5Bk7waGM@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
mashimiao.fnst-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org
Subject: Re: [PATCH_v4.1_3/3] Make core_pattern support namespace
Date: Wed, 22 Nov 2017 11:07:35 +0800 [thread overview]
Message-ID: <5A14E9F7.4070305@cn.fujitsu.com> (raw)
In-Reply-To: <8bb63f0a-d0b7-edf7-6dca-4d12641074b4-l3A5Bk7waGM@public.gmane.org>
Hi, Aleksa Sarai:
Sorry for the late replay.
> what happens if you have processes in the same pidns that have
different mount namespaces?
We support this. The coredump file will be saved in the same mount
namespace with the processes. This is implemented by patch
<Limit dump_pipe program's permission to init for container>
> Just my $0.02.
Thanks.
Best Regards
Cao ShuFeng
在 2017年08月02日 15:07, Aleksa Sarai 写道:
>> Currently, each container shared one copy of coredump setting
>> with the host system, if host system changed the setting, each
>> running containers will be affected.
>> Same story happened when container changed core_pattern, both
>> host and other container will be affected.
>>
>> For container based on namespace design, it is good to allow
>> each container keeping their own coredump setting.
>
> From what I can see, this is basically setting a per-pidns
> core_pattern (which is hierarchically applied). I'm not sure this
> actually solves the more general problem (that usermode helper
> settings aren't generally namespace-aware) -- and what happens if you
> have processes in the same pidns that have different mount namespaces?
>
> If we _had_ to do it like this I would think it makes more sense to
> pin it to mountns, but I was under the impression that someone was
> working on making usermode helpers play nicer with namespaces.
>
> Just my $0.02.
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: 曹树烽 <caosf.fnst@cn.fujitsu.com>
To: Aleksa Sarai <asarai@suse.de>, <linux-kernel@vger.kernel.org>
Cc: <containers@lists.linux-foundation.org>,
<mashimiao.fnst@cn.fujitsu.com>, <ebiederm@xmission.com>
Subject: Re: [PATCH_v4.1_3/3] Make core_pattern support namespace
Date: Wed, 22 Nov 2017 11:07:35 +0800 [thread overview]
Message-ID: <5A14E9F7.4070305@cn.fujitsu.com> (raw)
In-Reply-To: <8bb63f0a-d0b7-edf7-6dca-4d12641074b4@suse.de>
Hi, Aleksa Sarai:
Sorry for the late replay.
> what happens if you have processes in the same pidns that have
different mount namespaces?
We support this. The coredump file will be saved in the same mount
namespace with the processes. This is implemented by patch
<Limit dump_pipe program's permission to init for container>
> Just my $0.02.
Thanks.
Best Regards
Cao ShuFeng
在 2017年08月02日 15:07, Aleksa Sarai 写道:
>> Currently, each container shared one copy of coredump setting
>> with the host system, if host system changed the setting, each
>> running containers will be affected.
>> Same story happened when container changed core_pattern, both
>> host and other container will be affected.
>>
>> For container based on namespace design, it is good to allow
>> each container keeping their own coredump setting.
>
> From what I can see, this is basically setting a per-pidns
> core_pattern (which is hierarchically applied). I'm not sure this
> actually solves the more general problem (that usermode helper
> settings aren't generally namespace-aware) -- and what happens if you
> have processes in the same pidns that have different mount namespaces?
>
> If we _had_ to do it like this I would think it makes more sense to
> pin it to mountns, but I was under the impression that someone was
> working on making usermode helpers play nicer with namespaces.
>
> Just my $0.02.
>
next prev parent reply other threads:[~2017-11-22 3:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 6:37 [PATCH 0/3] Make core_pattern support namespace Cao Shufeng
2017-08-02 6:37 ` [PATCH_v4.1_1/3] Make call_usermodehelper_exec possible to set namespaces Cao Shufeng
2017-08-02 6:37 ` [PATCH_v4.1_2/3] Limit dump_pipe program's permission to init for container Cao Shufeng
2017-08-02 6:37 ` [PATCH_v4.1_3/3] Make core_pattern support namespace Cao Shufeng
[not found] ` <1501655849-9149-4-git-send-email-caosf.fnst-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2017-08-02 7:07 ` Aleksa Sarai
2017-08-02 7:07 ` Aleksa Sarai
[not found] ` <8bb63f0a-d0b7-edf7-6dca-4d12641074b4-l3A5Bk7waGM@public.gmane.org>
2017-11-22 3:07 ` 曹树烽 [this message]
2017-11-22 3:07 ` 曹树烽
[not found] ` <1501655849-9149-1-git-send-email-caosf.fnst-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2017-08-02 6:37 ` [PATCH_v4.1_1/3] Make call_usermodehelper_exec possible to set namespaces Cao Shufeng
2017-08-02 6:37 ` [PATCH_v4.1_2/3] Limit dump_pipe program's permission to init for container Cao Shufeng
2017-08-02 6:37 ` [PATCH_v4.1_3/3] Make core_pattern support namespace Cao Shufeng
2017-11-02 5:41 ` [PATCH 0/3] " 曹树烽
2017-11-02 5:41 ` 曹树烽
2017-11-22 3:24 ` [PATCH_v4.1 " Cao Shufeng
2017-11-22 3:24 ` Cao Shufeng
[not found] ` <1511321058-6089-1-git-send-email-caosf.fnst-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2017-11-22 3:24 ` [PATCH_v4.1 1/3] Make call_usermodehelper_exec possible to set namespaces Cao Shufeng
2017-11-22 3:24 ` [PATCH_v4.1 2/3] Limit dump_pipe program's permission to init for container Cao Shufeng
2017-11-22 3:24 ` [PATCH_v4.1 3/3] Make core_pattern support namespace Cao Shufeng
2017-11-22 3:24 ` [PATCH_v4.1 1/3] Make call_usermodehelper_exec possible to set namespaces Cao Shufeng
2017-11-22 3:24 ` [PATCH_v4.1 2/3] Limit dump_pipe program's permission to init for container Cao Shufeng
2017-11-22 3:24 ` [PATCH_v4.1 3/3] Make core_pattern support namespace Cao Shufeng
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=5A14E9F7.4070305@cn.fujitsu.com \
--to=caosf.fnst-bthxqxjhjhxqfuhtdcdx3a@public.gmane.org \
--cc=asarai-l3A5Bk7waGM@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mashimiao.fnst-BthXqXjhjHXQFUHtdCDX3A@public.gmane.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 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.