From: "Kawai, Hidehiro" <hidehiro.kawai.ez@hitachi.com>
To: Pavel Machek <pavel@ucw.cz>, Andrew Morton <akpm@osdl.org>
Cc: kernel list <linux-kernel@vger.kernel.org>,
sugita <yumiko.sugita.yf@hitachi.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Satoshi OSHIMA <soshima@redhat.com>,
"Hideo AOKI@redhat" <haoki@redhat.com>
Subject: Re: [PATCH 4/4] coredump: documentation for proc and sysctl]
Date: Tue, 30 Jan 2007 16:40:25 +0900 [thread overview]
Message-ID: <45BEF669.1060600@hitachi.com> (raw)
In-Reply-To: <20070126165847.GB1269@elf.ucw.cz>
Hi Pavel and Andrew,
Pavel Machek wrote:
>>This patch adds the documentation for the following parameters:
>> /proc/<pid>/core_flags
>> /proc/sys/kernel/core_flags_enable
>
> Sysctl seems really strange to me. Either the feature is safe to use,
> or it is not. Users can already ulimit -c 0, and we do not have
> "/proc/sys/kernel/allow_users_to_disable_their_core_dumps".
Oh, I had forgotten that. Thank you for pointing out. The purpose of
this sysctl is to prevent a bad process from hiding its memory.
But as you say, this sysctl isn't enough for the purpose.
Andrew wrote:
> Does this feature have any security implications? For example, there might
> be system administration programs which force a coredump on a "bad"
> process, and leave the core somewhere for the administrator to look at.
I have never heard of the story that ulimit -c 0 bothered an
administrator who wanted to force a coredump. So even without this
sysctl, the administrator wouldn't bother about security concerns.
I'll drop it from the next version.
Thanks,
--
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory
prev parent reply other threads:[~2007-01-30 7:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <45BA0E41.2080204@hitachi.com>
2007-01-26 16:58 ` [Fwd: [PATCH 4/4] coredump: documentation for proc and sysctl] Pavel Machek
2007-01-30 7:40 ` Kawai, Hidehiro [this message]
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=45BEF669.1060600@hitachi.com \
--to=hidehiro.kawai.ez@hitachi.com \
--cc=akpm@osdl.org \
--cc=haoki@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=pavel@ucw.cz \
--cc=soshima@redhat.com \
--cc=yumiko.sugita.yf@hitachi.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.