linux-kernel - Re: [PATCH 2/2] core: allow setrlimit to non-current tasks

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: <4A9FC8DA.4090001@gmail.com>
Date:	Thu, 03 Sep 2009 15:47:06 +0200
From:	Jiri Slaby <jirislaby@...il.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	akpm@...ux-foundation.org, mingo@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] core: allow setrlimit to non-current tasks

On 09/02/2009 11:51 PM, Oleg Nesterov wrote:
> On 09/02, Jiri Slaby wrote:
>> I can't think of anything else than doing all the checks and updates
>> under alloc_lock, introducing coarse grained static mutex in setrlimit
>> to protect it,
> 
> Oh, please don't ;)
> 
> Or I missed your point?
> 
> 
> But if you mean this series, then yes, I agree. 

Yes, I meant those. But I don't know what do you agree with :).

> We should try to do something
> to ensure that at least rlim_max can be always lowered when admin writes to
> /proc/pid/limits.

Yes, that's what I asked about when I wrote the three options which I
was able to think of above. So any other ideas about how to elegantly
protect against sys_setrlimit vs. admin+/proc/*/limits race?

Thanks a heap.
--
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/