linux-kernel - Re: [PATCH 0/4] coredump: core dump masking support v4

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070328103223.0473efc3.akpm@linux-foundation.org>
Date:	Wed, 28 Mar 2007 10:32:23 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>
Cc:	kernel list <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>, Robin Holt <holt@....com>,
	David Howells <dhowells@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	sugita <yumiko.sugita.yf@...achi.com>,
	Satoshi OSHIMA <soshima@...hat.com>,
	Hideo AOKI <haoki@...hat.com>
Subject: Re: [PATCH 0/4] coredump: core dump masking support v4

On Wed, 28 Mar 2007 21:37:07 +0900 "Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com> wrote:

> >   Because other people might (reasonably) wish to omit anonymous memory,
> >   or private mappings, or file-backed VMAs, or whatever.
> > 
> >   So maybe /proc/pid/coredump_omit_anon_shared should become
> >   /proc/pid/core_dumpfilter, which is a carefully documented bitmask.
> 
> There are people who wish to dump VMAs which are not dumped by default.
> Taking this into account, some bits of core_dumpfilter will be set by
> default.  This means users have to be aware of the default bitmask
> when they change the bitmask.  Perhaps changing the bitmask requires
> 3 steps:
> 
>   1. read the default bitmask
>   2. change bits of the mask
>   3. write it to the proc entry
> 
> So I think it is better if we provide /proc/pid/core_flags (default:
> all bits are 0) instead of core_dumpfilter.  With this interface,
> users who use only one bit of the bitmask (this will be a common case) 
> just have to write 2^n to the proc entry.  It takes only one step:
> 
>  1. write a value to the proc entry
> 
> If we can implement at the same cost, core_flags will be better
> because it is useful for users.  What would you think about that?
> 

It sounds unnecessarily complex, and unnecessarily different from our
normal expectations of /proc files.  And the value we read differs from the
value we wrote...  I think having a non-zero default will be fine.

> 
> By the way, Robin Holt wrote as follows:
> 
> > Can you make this a little more transparent?  Having a magic bitmask does
> > not seem like the best way to do stuff.  Could you maybe make a core_flags
> > directory with a seperate file for each flag.  It could still map to a
> > single field in the mm, but be broken out for the proc filesystem.
> 
> Do you think Robin's suggestion is acceptable?

Marginal, I think.  This is not likely to be a field which a lot of people
modify a lot of times.  Those few people who need to work with this can
afford to look the values up in the documentation while writing their
script.

And it requires a distressingly large amount of code to implement a /proc
file.  Perhaps in this situation the code can be shared.

otoh, why is it a /proc thing at all?

unsigned long sys_set_corefile_filter(unsigned long enable_mask);
unsigned long sys_clear_corefile_filter(unsigned long enable_mask);

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