lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161026001938.GB2525@templeofstupid.com>
Date:   Tue, 25 Oct 2016 17:19:38 -0700
From:   Krister Johansen <kjlx@...pleofstupid.com>
To:     Cao Shufeng <caosf.fnst@...fujitsu.com>
Cc:     linux-kernel@...r.kernel.org,
        containers@...ts.linux-foundation.org,
        mashimiao.fnst@...fujitsu.com, ebiederm@...ssion.com
Subject: Re: [PATCH v4 3/3] Make core_pattern support namespace

On Tue, Oct 25, 2016 at 03:28:56PM +0800, Cao Shufeng wrote:
> From: Zhao Lei <zhaolei@...fujitsu.com>
> It will bring us following benefit:
> 1: Each container can change their own coredump setting
>    based on operation on /proc/sys/kernel/core_pattern
> 2: Coredump setting changed in host will not affect
>    running containers.
> 3: Support both case of "putting coredump in guest" and
>    "putting curedump in host".

Would you explain more about case #3 here?  In particular, I'm curious
what the impact is for systems that have already configured core_pattern
with the understanding that the program might be invoked to handle
either a host or a container core.  In particular, is there any way to
specify that the container handler fall back to the host handler?

On the systems that I've configured, /proc/sys is mounted read-only in the
container.  The host has a special program run from core_pattern that
determines which container generated the core.  It then stores the cores
in a directory that uniquely identifies the container.  The cores are
isolated on their own filesystem, and given a quota per-container.  The
eventual goal is to have a service evacuate the cores to an object store
where we can make them available to the customer via a web service.

Does your change still allow a global handler in the host to process
cores from containers?  Or is that behavior removed completely?

-K

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ