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]

Message-ID: <4BFD1ADD.7020004@gmail.com>
Date:	Wed, 26 May 2010 14:58:05 +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/14/2010 12:56 AM, Andrew Morton wrote:
> On Mon, 10 May 2010 20:00:50 +0200
> Jiri Slaby <jslaby@...e.cz> wrote:
> 
>> This patch adds the code to support the sys_prlimit64 syscall which
>> modifies-and-returns the rlim values of a selected process
>> atomically. The first parameter, pid, being 0 means current process.
>>
>> Unlike the current implementation, it is a generic interface,
>> architecture indepentent so that we needn't handle compat stuff
>> anymore. In the future, after glibc start to use this we can deprecate
>> sys_setrlimit and sys_getrlimit in favor to clean up the code finally.
>>
>> It also adds a possibility of changing limits of other processes. We
>> check the user's permissions to do that and if it succeeds, the new
>> limits are propagated online. This is good for large scale
>> applications such as SAP or databases where administrators need to
>> change limits time by time (e.g. on crashes increase core size). And
>> it is unacceptable to restart the service.
>>
>> For safety, all rlim users now either use accessors or doesn't need
>> them due to
>> - locking
>> - the fact a process was just forked and nobody else knows about it
>>   yet (and nobody can't thus read/write limits)
>> hence it is safe to modify limits now.
>>
>> The limitation is that we currently stay at ulong internal
>> representation. So we use the rlim64_is_infinity check where we
>> compare to ULONG_MAX on 32-bit which is the maximum value there.
>>
>> And since internally we hold limits in struct rlimit, we introduce
>> converters used before and after do_prlimit call in sys_prlimit64.
>>
> 
> Is this worth all the new code and the increase in locking dependencies
> which I think is there?

Sorry, for the late reply, I was busy with other things.

Both
tasklist_lock -> (task_struct->sighand->siglock)
tasklist_lock -> (task_struct->alloc_lock)
are OK, since both dependencies already exist in the kernel.

This should have been in the changelogs, yes!

> This could all be done in userspace, couldn't it?  Write a little library
> which clones a thread then waits for someone to send it a
> change-your-rlimits message.  Write a little tool to send those
> messages and voila.

Sorry, I'm not sure I understand this. Could you shed some light on what
will run in the new thread?

A code such as:
main()
{
  if (!clone())
    exec("something");

  while (wait_for_message(&m)) {
     setrlimit(m);
     sleep();
  }
}
won't obviously work. Could you change it so it reflects your idea or
explain what I'm missing?

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