linux-kernel - Re: [PATCH] binfmt_elf: core dump masking support

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: <45A74B89.4040100@hitachi.com>
Date:	Fri, 12 Jan 2007 17:49:13 +0900
From:	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	gregkh@...e.de, james.bottomley@...eleye.com,
	Satoshi OSHIMA <soshima@...hat.com>,
	"Hideo AOKI@...hat" <haoki@...hat.com>,
	sugita <yumiko.sugita.yf@...achi.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] binfmt_elf: core dump masking support

Hi,

>>>>  $ echo 1 > /proc/self/coremask
>>>>  $ ./some_program
>>>
>>>User can already ulimit -c 0 on himself, perhaps we want to use same
>>>interface here? ulimit -cmask=(bitmask)?
>>
>>Are you saying that 1) it is good to change ulimit (shell programs)
>>so that shell programs will read/write /proc/self/coremask when
>>the -cmask option is given to ulimit?
>>Or, 2) it is good to change ulimit and get/setrlimit so that shell
>>programs will invoke get/setrlimit with new parameter?

>>But the second approach is problematic because the bitmask doesn't
>>conform to the usage of setrlimit.  You know, setrlimit controls amount
>>of resources the system can use by the soft limit and hard limit.
>>These limitations don't suit for the bitmask.
> 
> Well, you can have it as set of 0-1 "limits"...

I have come up with a similar idea of regarding the ulimit
value as a bitmask, and I think it may work.
But it will be confusable for users to add the new concept of
0-1 limitation into the traditional resouce limitation feature.
Additionaly, this approach needs a modification of each shell
command.
What do you think about these demerits?

The /proc/<pid>/ approach doesn't have these demerits, and it
has an advantage that users can change the bitmask of any process
at anytime.

So I'm going to post the 2nd version patchset with /proc/<pid>/
interface.  If the 2nd version has crucial problems, I'll try
the ulimit approach.

Best regards,
-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory



-
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/