linux-kernel - Re: [RFC][PATCH][0/3] introduce rlimit cgroup

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] [day] [month] [year] [list]

Message-ID: <488AD656.5060801@miraclelinux.com>
Date:	Sat, 26 Jul 2008 16:46:30 +0900
From:	Hirofumi Nakagawa <hnakagawa@...aclelinux.com>
To:	linux-kernel@...r.kernel.org
CC:	Ram Gupta <ram.gupta5@...il.com>, Paul Menage <menage@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [RFC][PATCH][0/3] introduce rlimit cgroup

Hi,

Thank you for your comments.
I understand that.
I'll look for other approach for this.

thanks

> I understand that there might be some cases where it is useful to
> allow some process to set rlimits of other processes (e.g. some
> launcher process might want to control resources of all the
> applications being launched by it). But this has to be a very special
> case or this process needs to have special permission to do that
> otherwise there will be a lot of problems as a side effect.
> 
> Ram
> 
> On Fri, Jul 25, 2008 at 1:05 AM, Paul Menage <menage@...gle.com> wrote:
>>> To set rlimit from other processes is my original intention.
>>> For I do not see a way to do it, please let me know if there were any
>>> exists.
>> No, there's no way to do that currently. I'm not sure if it's
>> generally safe to update the rlimit for another process.
>>
>> If we're trying to use rlimits in a cgroup context then some rlimits
>> (e.g. max nice priority) ought to apply as additional caps on the
>> processes in the cgroup (e.g. if you set a max nice priority of 1 on a
>> cgroup, that ought to override any per-process settings) whereas
>> others (e.g. locked memory, open files, num processes) ought to apply
>> as an aggregate limit on the cgroup (so the sum of all open files
>> across the cgroup shouldn't be able to exceed the cgroup's "open
>> files" limit). E.g. see Balbir's memrlimit control groups patches that
>> are currently in -mm.
>>
>> What concrete problem are you trying to solve here?
>>
>> Paul
>> --
>> 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/
>>
> 

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