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]
Message-ID: <20080826160007.GE30312@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ