linux-kernel - Re: [RFC] How to handle the rules engine for cgroups

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:	Thu, 10 Jul 2008 13:25:46 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Paul Menage <menage@...gle.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Libcg Devel Mailing List <libcg-devel@...ts.sourceforge.net>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Peter Zijlstra <pzijlstr@...hat.com>,
	Kazunaga Ikeno <k-ikeno@...jp.nec.com>,
	Morton Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Graf <tgraf@...hat.com>
Subject: Re: [RFC] How to handle the rules engine for cgroups

On Thu, 10 Jul 2008 08:56:25 -0700
Ulrich Drepper <drepper@...hat.com> wrote:

> Once the information is available, how is it used?  We'd have to pass
> additional information to the exec syscalls.  And it has to happen so
> that if the exec call fails the original process is not affected (i.e.,
> premature changing isn't an option).  The method also must be
> thread-safe in a limited way: executing failing exec syscalls in
> multiple threads mustn't disturb the process.

One easy way is to have a "migrate on exec" option added to the
process group code.  Instead of moving yourself to a new process
group before exec, you do the same invocation but with a "migrate
me lazily at exec time" flag.

At exec time, your current resources will be subtracted from the
old process group (most of it automatically in exit_mmap) and your 
new resources will be added to the new process group on the other 
side of exec.

The exec syscall itself does not need to change.

> There is one set of problems which I don't care about but others likely
> will: what happens if some program uses the syscalls directly?  And what
> happens with old libcs and old statically linked programs?  It's exactly
> the kind of problem why I tell people to never linked statically but
> some people don't listen.

Those people will have to move their processes around between
process groups manually (or with shell scripts).  Having per
program process groups is essentially bonus functionality
over the "start daemon in own process group" and "start user
in own process group" functionalities.

Whether and how we want to implement this is open for discussion.

Personally I suspect that a kernel side rule-based engine with
user loadable rules may not be the best idea :)

-- 
All Rights Reversed
--
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/