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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080714135719.GE16673@redhat.com>
Date:	Mon, 14 Jul 2008 09:57:19 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	Rik van Riel <riel@...hat.com>, Paul Menage <menage@...gle.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>,
	Ulrich Drepper <drepper@...hat.com>
Subject: Re: [RFC] How to handle the rules engine for cgroups

On Fri, Jul 11, 2008 at 09:55:01AM +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 10 Jul 2008 11:40:35 -0400
> Vivek Goyal <vgoyal@...hat.com> wrote:
> 
> > On Thu, Jul 10, 2008 at 10:48:52AM -0400, Rik van Riel wrote:
> > > On Thu, 10 Jul 2008 02:23:52 -0700
> > > "Paul Menage" <menage@...gle.com> wrote:
> > > 
> > > > I don't see the rule-based approach being all that useful for our needs.
> > > 
> > > Agreed, there really is no need for a rule-based approach in kernel space.
> > > 
> > > There are basically three different cases:
> > > 
> > > 1) daemons get started up in their own process groups, this can
> > >    be handled by the initscripts
> > > 
> > > 2) user sessions (ssh, etc) start in their own process groups,
> > >    this can be handled by PAM
> > > 
> > > 3) users fork processes that should go into special process
> > >    groups - this could be handled by having a small ruleset
> > >    in userspace handle things, right before calling exec(),
> > 
> > That means application launcher (ex, shell) is aware of the right cgroup
> > targeted application should go in and then move forked pid to right
> > cgroup and call exec? Or you had something else in mind?
> >  
> > >    it can even be hidden from the application by hooking into
> > >    the exec() call
> > > 
> > 
> > This means hooking into libc. So libc will parse rules file, determine
> > the right cgroup, place application there and then call exec?
> > 
> 
> Hmm, as I wrote, the rule that the child inherits its own parent't is very
> strong rule. (Most of case can be handle by this.) So, what I think of is
> 
> 1. support a new command (in libcg.)
>   - /bin/change_group_exec ..... read to /etc/cgroup/config and move cgroup
>                                  and call exec.
> 2. and libc function
>   - if necessary.
> 
> 1. is enough because admin/user can write a wrapper script for their
> applications if "child inherits parent's" isn't suitable.
> 
> no ?
> 

If admin has decided to group applications and has written the rules for
it then applications should not know anything about grouping. So I think
application writing an script for being placed into the right group should
be out of question. Now how does an admin write a wrapper around existing
application without breaking anything else.

One thing could be creating soft links where admin created alias points
to wrapper and wrapper inturn invokes the executable. But this will not
solve the problem if some user decides to invoke the application
executable directly and not use admin created alias. 

Did you have something else in mind when it came to creating wrappers
around applications?

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