Bug 760264 - cgconfig.conf sets improper group permissions
Summary: cgconfig.conf sets improper group permissions
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libcgroup
Version: 16
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Schiffer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-05 17:49 UTC by Shawn Bohrer
Modified: 2012-07-11 05:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-11 05:11:28 UTC
Type: ---


Attachments (Terms of Use)

Description Shawn Bohrer 2011-12-05 17:49:27 UTC
Description of problem:

Using /etc/cgconfig.conf to create cgroups and set permissions on those groups does not set proper permissions for the gid.  The cgconfig.conf man page says in the "permissions" section:

      task user/group  Name  of  the  user  and the group, which owns
                       tasks file of the  control  group.  I.e.  this
                       user  and  members  of  this  group  has write
                       access to the file.

      admin user/group Name of the user and the group, which owns the
                       rest of control group's files. These users are
                       allowed to set subsystem parameters and create
                       subgroups.

So specifically I would expect the gid to have write access to the directory and files.


Version-Release number of selected component (if applicable):

libcgroup-0.37.1-4.fc16.x86_64
libcgroup-tools-0.37.1-4.fc16.x86_64

How reproducible:

very

Steps to Reproduce:
1. Create /etc/cgconfig.conf with user/group names.
  
Actual results:

$ cat /etc/cgconfig.conf
mount {
    cpuset  = /cgroup/cpuset;
}

group . {
    perm {
        task {
            uid = root;
            gid = cg;
        }
        admin {
            uid = root;
            gid = cg;
        }
    }
    cpuset {
    }
}

$ ls -ld /cgroup/cpuset
drwxr-xr-x 3 root cg 0 Dec  2 11:27 /cgroup/cpuset

$ ls -l /cgroup/cpuset/
total 0
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cgroup.clone_children
--w--w--w- 1 root cg 0 Dec  2 11:27 cgroup.event_control
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cgroup.procs
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.cpu_exclusive
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.cpus
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.mem_exclusive
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.mem_hardwall
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.memory_migrate
-r--r--r-- 1 root cg 0 Dec  2 11:27 cpuset.memory_pressure
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.memory_pressure_enabled
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.memory_spread_page
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.memory_spread_slab
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.mems
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.sched_load_balance
-rw-r--r-- 1 root cg 0 Dec  2 11:27 cpuset.sched_relax_domain_level
-rw-r--r-- 1 root cg 0 Dec  2 11:27 notify_on_release
-rw-r--r-- 1 root cg 0 Dec  2 11:27 release_agent
-rw-r--r-- 1 root cg 0 Dec  2 11:27 tasks

Expected results:

In example above group "cg" should have write access in addition to the user root.

Comment 1 Shawn Bohrer 2012-01-24 20:00:46 UTC
Browsing the upstream git repo there are a couple of commits that have landed since 0.37.1 which look like they would help solve this issue.

git://libcg.git.sourceforge.net/gitroot/libcg/libcg

c89f2e79a35d0e5f74eabdda60c7f0097791d94f cgconfig: enable setting file permissions
34827fbc08067e4a4a2813c62b53bc40f8118390 Permissions settings documentation
dfd9effc8de62e99778ee0ea44f5877ed2dedcb9 cgconfigparser: Allow SUID and SGID permissions in 'fperm' and 'dperm' options.
593ed38e0225691974cdf56c420b56c5987716ee cgconfigparser: Added options to set default owners/permissions.


Note You need to log in before you can comment on or make changes to this bug.