linux-kernel - Re: [PATCH v3 10/11] rlimits: implement prlimit64 syscall

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]

Date:	Wed, 26 May 2010 17:13:38 +0200
From:	Jiri Slaby <jirislaby@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	adobriyan@...il.com, nhorman@...driver.com, oleg@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 10/11] rlimits: implement prlimit64 syscall

On 05/26/2010 04:30 PM, Andrew Morton wrote:
> main()
> {
> 	if (clone(...)) {
> 		while (wait_for_message(&m))
> 			setrlimit(m);
> 	}
> 
> 	...
> }
> 		
> ?

Hmm. Probably I'm still missing something obvious, but how does this
help for existing services like databases and/or closed-source products?

Or do you mean to provide this as a library
(s@...n@...ttribute__((constructor)) my_main@ then) and link (or even
preload) to the programs people want to change limits on-the-fly in?
(And clone with THREAD flag to share task_struct->signal.)

But this approach can only help for the parent of all the forked-later
processes. Especially if a process forks and exits (i.e. creates a
daemon), the child running in the background doesn't have the
wait_for_message thread. So if it forks again (e.g. to service a new
request) the limits cannot be changed in any of them.

This can be solved by adding such a cloned-thread loop into every forked
child, but I'm not sure this is something we want.

In addition, people don't know which process will need to change limits
in advance. Every single binary would have to contain such code.

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