Re: [Propose] Isolate core_pattern in mnt namespace.

[Eric W. Biederman]

Dongsheng Yang <yangds.fnst@xxxxxxxxxxxxxx> writes:

> On 12/22/2015 05:52 AM, Eric W. Biederman wrote:
>> For your case that sounds like it would work.  Unfortunately for this to
>> be generally applicable and to let the OS in the contianer control it's
>> fate the core dump pattern needs to be supported.
>>
>> Otherwise something clever in userspace that can be written now should
>> be sufficient to fill the gap.  There is enough information for the user
>> mode helper to implement the policy you would like today.
>
> Hi Eric,
>
> To make sure I understand your point correctlyï
> 	Do you mean we can write a userspace helper in host such as
> /usr/libexec/docker-pipe to get what I want?
>
> Yes, I would say, for my case, it would work. This helper can get the
> dump data from containers and dispatch them to different path such
> as /var/lib/docker/cores/<ContainerID>/.

Yes.  And there is enough information present at that time it can
save the core dumpes inside the container the application was
running in.

> But there would be two problems in this solution.
> (1). It may affect core dump on host. Normally, other processes in
>  host would not be happy to use a helper of docker-pipe for themselves.
>  But host have to share the core_pattern with containers, can't config
>  it by itself.

So far figuring out how to share the core dump helper appears simpler
than fixing user mode helper.

> (2). If there are some containers don't want to pass the core files
> to host, they can't set the core_pattern in this solution.

Again so far fixing that in user space appears to be more tractable
and easier than anything that has been proposed kernel side.

> IMO, we can get core files on host currently, by either non-pipe way I
> described above or the pipe way you suggested. But the problem is both
> of these methods would affect the core_pattern on host and other
> containers.
>
> So, I think the key point here is just isolating the core dump related
> sysctl in mnt namespace.

You don't have to convince me it would be nice to do.  You have to
convince me it is practical to implement.  Which is an entirely
different problem.

Given the other constraints on an implementation the pid namespace looks
by far the one best suited to host such a sysctl if it is possible to
implement safely.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/