Bug 758493

(In reply to comment #0)
> Request Type: Package - Feature from Upstream
> d. Upstream Acceptance: Accepted

Could you please specify, which patches are requested? I do not recall any specific functionality for large pages in libcgroups added recently.

Or do you request new controllers/parameters/functionality directly in Linux kernel? Please use 'kernel' component if so, libcgroup package is just user-space library and collection of simple tools to help applications manage cgroups.

------- Comment From hohnbaum.com 2011-12-05 19:24 EDT-------
Sorry, we got our messages crossed internally at IBM on this item.  We need the 0.37-3 version of libcgroup to pick up a critical bug fix for our LoadLeveler product, or if not a version upgrade, then a patch from that version incorporated into the version shipping with RHEL 6.x.

We are also working on large page support for cgroups, but that is indeed a kernel change and has not yet been submitted upstream.  We will be requesting that support in the RHEL 7.0 release.

Ciju will provide details on the bug fix along with the patch.  We will update the bugzilla summary line to reflect the specific fix we are looking for.

------- Comment From cijurajan.com 2011-12-20 00:00 EDT-------
Hello Redhat,

There was one bug related to assign/admin id in libcgroup. This is fixed is in the mainline version. This bug fix is needed for one of our product to work properly.

Here is the patch that fixes this problem:
http://libcg.git.sourceforge.net/git/gitweb.cgi?p=libcg/libcgroup-context.git;a=commit;h=17a40d649c9dfc539b18784c644d8a45916ecd68

Description:

admin_id and admin_gid are not displayed correctly. This is because cgroup_fill_cgc() does not differentiate between the cgroup control files and tasks file. So cgroup->control_uid and cgroup->control_gid fields are getting populated with the uid and gid of tasks file.

This patch fixes this problem by adding a check in the cgroup_fill_cgc() function to see if the file is a 'tasks' file or not.

Please pick this patch into libcgroup version that will be included in RHEL6.3. Or take the latest mainline version of libcgroup, in which this problem is fixed.

-Ciju

IBM is signed up to test and provide feedback, setting OtherQA.

------- Comment From cijurajan.com 2011-12-22 08:14 EDT-------
Redhat,

Attaching the patch also. Please include it in RHEL6.3.

-Ciju

Created attachment 549191 [details]
Patch to fix the admin/assign id bug


------- Comment (attachment only) From cijurajan.com 2011-12-22 08:15 EDT-------

This request was evaluated by Red Hat Product Management for inclusion in the
current release of Red Hat Enterprise Linux. Because the affected component is
not scheduled to be updated in the current release, Red Hat is unfortunately
unable to address this request at this time.  It has been proposed for the next
release. If you would like it considered as an exception in the current
release, please ask your support representative.

------- Comment From tpnoonan.com 2012-02-13 13:12 EDT-------
hi red hat, can you reconsider for rhel6.3 based on the following? many thanks

> The problem being addressed by this request affects the HPC related product -
> LoadLeveler.  Please escalate this rejection with Red Hat.  Thanks.
> Problem:
> When we invoke cgroup_get_cgroup() in libcgroup library to get the cgroup meta
> data, the admin_id and admin_gid are not displayed correctly. This is because
> cgroup_fill_cgc() does not differentiate between the cgroup control files and
> tasks file. So cgroup->control_uid and cgroup->control_gid fields are getting
> populated with the uid and gid of tasks file
> Business impact:
> Load Leveler software has the functionality to give privileges to certain users
> to administer the cgroup and also the power to assign tasks to the groups based
> on the configuration suggested by the administrator. This feature will not work
> because of this bug in libcgroup package. According to Load Leveler team, this
> is a critical feature.

------- Comment From markwiz.com 2012-04-25 20:38 EDT-------
Red Hat- John Jarvis at Red Hat has ask us to test this. Which build will the fix be in for us to test?

(In reply to comment #18)
> Red Hat- John Jarvis at Red Hat has ask us to test this. Which build will the
> fix be in for us to test?

libcgroup-0.37-4 in 6.3 Beta

IBM, have you been able to test and verify this?

------- Comment From hbaum.com 2012-05-22 15:37 EDT-------
Verified by IBM.  Tester will provide more details.

------- Comment From raghavendra.kt.com 2012-05-23 06:11 EDT-------
(In reply to comment #25)
> Verified by IBM.  Tester will provide more details.

Here are the brief l steps with the test program

assign_admin_test.c
#include <libcgroup.h>
/*
* Compilation:
*  gcc -g assign_admin_test.c -lcgroup -I /usr/include/ -I /usr/include/libcgroup/
* test performed:
* step 1)
* create a new user and have his permission for tasks file by updating in cgconfig.conf
* similar like this.
*
*
group newuser {
perm {
admin {
uid = root;
gid = root;
}
task {
uid = newuser;
gid = newuser;
}
}
memory {
memory.limit_in_bytes = 512M;
}

step 2) Have this entry in cgrules.conf
newuser     *               /newuser
step 3) restart cgconfig check for /cgroup/<controlgroup>/newuser
step 4) create a test directory under /cgroup/<controlgroup>/newuser
controlgroup for e.g here is memory
step 5) execute the test binary, you should not see control_uid/gidoverwritten with task uid/gid
in the example task uid/gid is newuser and control uid/gid is  root
*/
int main ()
{
int ret;
struct cgroup *cgroup;

ret = cgroup_init();
if (ret) {
printf(" error cgroup init\n");
goto error;
}
cgroup = cgroup_new_cgroup("newuser/test");

ret = cgroup_get_cgroup(cgroup);
if (ret) {
printf(" error getcgroup \n");
goto error;
}

ret = cgroup_attach_task_pid(cgroup, getpid());
if (ret) {
printf(" error attach task \n");
goto error;
}
getchar();
cgroup_free(&cgroup);
return 0;
error:

return 1;
}

(In reply to comment #22)
> ------- Comment From raghavendra.kt.com 2012-05-23 06:11 EDT-------
> (In reply to comment #25)
> > Verified by IBM.  Tester will provide more details.
> 
> Here are the brief l steps with the test program
> 
> assign_admin_test.c
> #include <libcgroup.h>
> /*
> * Compilation:
> *  gcc -g assign_admin_test.c -lcgroup -I /usr/include/ -I
> /usr/include/libcgroup/
> * test performed:
> * step 1)
> * create a new user and have his permission for tasks file by updating in
> cgconfig.conf
> * similar like this.
> *
> *
> group newuser {
> perm {
> admin {
> uid = root;
> gid = root;
> }
> task {
> uid = newuser;
> gid = newuser;
> }
> }
> memory {
> memory.limit_in_bytes = 512M;
> }

An extra closing bracket is needed here. 'newuser' user/group need to be created too.

> step 2) Have this entry in cgrules.conf
> newuser     *               /newuser
> step 3) restart cgconfig check for /cgroup/<controlgroup>/newuser
> step 4) create a test directory under /cgroup/<controlgroup>/newuser
> controlgroup for e.g here is memory
> step 5) execute the test binary, you should not see
> control_uid/gidoverwritten with task uid/gid
> in the example task uid/gid is newuser and control uid/gid is  root

I can get the program to run as root with the above steps but I do not understand how to verify the control uid/gid is not overwritten with task uid/gid

How do you check the control uid/gid?

------- Comment From raghavendra.kt.com 2012-05-25 12:30 EDT-------
(In reply to comment #29)
> (In reply to comment #22)
> > (In reply to comment #25)
> > > Verified by IBM.  Tester will provide more details.
> >
> > Here are the brief l steps with the test program
> >
> > assign_admin_test.c
> > #include <libcgroup.h>
> > /*
> > * Compilation:
> > *  gcc -g assign_admin_test.c -lcgroup -I /usr/include/ -I
> > /usr/include/libcgroup/
> > * test performed:
> > * step 1)
> > * create a new user and have his permission for tasks file by updating in
> > cgconfig.conf
> > * similar like this.
> > *
> > *
> > group newuser {
> > perm {
> > admin {
> > uid = root;
> > gid = root;
> > }
> > task {
> > uid = newuser;
> > gid = newuser;
> > }
> > }
> > memory {
> > memory.limit_in_bytes = 512M;
> > }
> An extra closing bracket is needed here. 'newuser' user/group need to be
> created too.
> > step 2) Have this entry in cgrules.conf
> > newuser     *               /newuser
> > step 3) restart cgconfig check for /cgroup/<controlgroup>/newuser
> > step 4) create a test directory under /cgroup/<controlgroup>/newuser
> > controlgroup for e.g here is memory
> > step 5) execute the test binary, you should not see
> > control_uid/gidoverwritten with task uid/gid
> > in the example task uid/gid is newuser and control uid/gid is  root
>
> I can get the program to run as root with the above steps but I do not
> understand how to verify the control uid/gid is not overwritten with task
> uid/gid
>
> How do you check the control uid/gid?

One method is debugging with gdb and cross checking that control uid/gid has not been overwritten
with task uid/gid.

(In reply to comment #24)
> One method is debugging with gdb and cross checking that control uid/gid has
> not been overwritten
> with task uid/gid.

Thanks, I was unable to verify this personally but the patch is included in the source rpm and is applied successfully during build of the errata packages for each arch:

[jbrier@jb-t520 logs]$ pwd
/mnt/curly/redhat/brewroot/packages/libcgroup/0.37/4.el6/data/logs
[jbrier@jb-t520 logs]$ for i in `ls`; do grep admin-assign-id.patch $i/build.log; done;
Patch #6 (libcgroup-0.37-admin-assign-id.patch):
+ echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):'
+ /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch
Patch #6 (libcgroup-0.37-admin-assign-id.patch):
+ echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):'
+ /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch
Patch #6 (libcgroup-0.37-admin-assign-id.patch):
+ echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):'
+ /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch
Patch #6 (libcgroup-0.37-admin-assign-id.patch):
+ echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):'
+ /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch
Patch #6 (libcgroup-0.37-admin-assign-id.patch):
+ echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):'
+ /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch
+ echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):'
Patch #6 (libcgroup-0.37-admin-assign-id.patch):
+ /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch


IBM has tested/verified this and the IBM Verified is set. Additionally marking SanityOnly

Adding SanityOnly back, IBM please do not remove this.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0867.html