linux-kernel - Re: [git pull] pull request for writable limits for 2.6.34-rc0

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, 24 Mar 2010 18:02:13 +0100
From:	Jiri Slaby <jirislaby@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Alexey Dobriyan <adobriyan@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Neil Horman <nhorman@...driver.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [git pull] pull request for writable limits for 2.6.34-rc0

Hi.

On 03/21/2010 07:38 PM, Linus Torvalds wrote:
> Yeah, the infinity setting should be cleaned up. I also wonder if we 
> should clean up the odd file limit rules, and make them all be about 
> bytes. Correct me if I'm wrong, but don't we do that whole file size thing 
> in kilobytes right now?

Nope, it's just ulimit in bash who takes "blocks" and calls setrlimit
with 1024*value for core and file size limits.

> I do also agree that maybe we could/should skip the whole "writable /proc" 
> thing.

I agree too, why I had to implement is that we cannot assign syscall
numbers before merging upstream (for obvious reasons of not destroying
userspace interface where programs won't work on our distro) and we
needed the writable-limits feature.

> Or even just _one_ system call that takes two pointers, and can do an 
> atomic replace-and-return-the-old-value, like 'sigaction()' does, ie 
> something like
> 
> 	int prlimit64(pid, limit, const struct rlimit64 *new, struct rlimit64 *old);
> 
> wouldn't that be a nice generic interface?

Seconded. But should the limits be by default 64-bit even on 32-bit? I
mean: switch 'struct limit' in signal_struct to 'struct rlimit64'? This
would make the limits non-atomic on 32-bit. Oh, they are not already if
reader wants both cur and max without any locks, but I'm not sure now
what implications this will have (I haven't checked compilers, but I
think a store of 00000001 0000000 in place of 00000000 ffffffff may
result in a read of 00000001 ffffffff or alike). Or did I misunderstand you?

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/