On Thu, Feb 10, 2011 at 5:41 AM, Ken'ichi Ohmichi
<oomi...@mxs.nes.nec.co.jp> wrote:
>
> Hi,
>
> On Tue, 08 Feb 2011 15:35:48 +0100
> Jiri Slaby <jsl...@suse.cz> wrote:
>>
>> ============================
>>
>>
>> cgrules.conf are as simple as:
>> xslaby * cpu0/
>> man * cpu1/
>> * * others/
>>
>>
>> ============================
>>
>>
>> And now if I run the program under root as:
>> # cgexec -g *:cpu1 --sticky ./fork
>> the children are moved into the cpu0 group despite the sticky option.
>> The same as for non-sticky case.
>
> Thank you for testing.
>
>> static void child(unsigned int id)
>> {
>> if (setuid(1000))
>> err(2, "setuid");
>> sleep(5+id);
>> exit(id);
>> }
>
> I can reproduce this problem by using your test program.
> And if removing setuid(1000) call the program, the children are *not*
> moved to the other group.
>
> The source problem is that a cgrulesengd daemon does not check whether
> a sticky process when setuid(2)/setgid(2) happens.
>
> The attached patch fixes this problem.
>
>
> After applying this patch, a cgroulesengd daemon doesn't move a stickied
> process like the following:
>
Thanks, I will merge it in a bit!
Dhaval
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel
