linux-kernel - Re: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right 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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Aug 2008 12:00:07 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	David Collier-Brown <davecb@....com>
Cc:	balbir@...ux.vnet.ibm.com, Paul Menage <menage@...gle.com>,
	righi.andrea@...il.com,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.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>,
	Steve Olivieri <solivier@...hat.com>
Subject: Re: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes
	efficiently in the right cgroup

On Tue, Aug 26, 2008 at 11:04:42AM -0400, David Collier-Brown wrote:
> Balbir Singh wrote:
>> Applications that really care about moving should use cgroup_attach_task* and
>> move back otherwise with cgrules parsing turned off.
>>
>> I see control as a two level hierarchy, automatic and controlled, how do we make
>> sure that they don't conflict is something I have not thought about yet.
> [...]
>
>> Hmm... I wonder if we are providing too many knobs. Can't we do something simpler?
>
> Solaris doesn't try to change cgroup ("project") on a setuid call, assuming
> the program is in the proper cgroup initially.  For most cases this is
> trivially true under the very simple default rules, and for the rest one
> can create a rule or a startup script that sets it with newtask".
>

Who executes default rules? IOW, how do you make sure tasks of user.davecb
end up in project 101 only and not outside?

> The Sun default is
> 	$ cat /etc/project
> 	system:0::::
> 	user.root:1::::
> 	noproject:2::::
> 	default:3::::
> 	group.staff:10::::
>
> Which means that root users are distinguished from users in
> the staff group, and they are distinguished from daemons
> and everyone else.
>

Now Linux also will allow admin to specify simple rules in
/etc/cgrules.conf. Rules are based basically on premise that users/groups
own resources in a particular cgroup and one can specify which cgroup
the task should run in. For ex.

#john          cpu              usergroup/faculty/john/
#@...dent      cpu,memory       usergroup/student/
#@...t          *               admingroup/
#*              *               default/

This simply means which user/group's tasks should run in what cgroup for
which controller. (There are some wild cards also). For details, you can
check out libcg-devel source tree and documentation files.

> Personally, I add
> 	user.davecb:101::davecb::
> 	bg:100:Background jobs:davecb::
> which puts me in a separate cgroup, and provides another one
> for me to put background tasks into.  The latter allows
> me to keep them from reducing the interactive performance of
> my laptop. 

So by default all the tasks of user.davecb will run into project 101 until
user davecb decides to launch some background jobs in project 100 using
newtask?

"newtask" like functionality is being provided by a new command line tool
"cgexec" which will allow launching of a new task in specific cgroup
(project).

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/