| Summary: | cgconfig.conf sets improper group permissions | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Shawn Bohrer <shawn.bohrer> |
| Component: | libcgroup | Assignee: | Peter Schiffer <pschiffe> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | bsingharora, jsafrane, pschiffe, varekova |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-07-11 05:11:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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. |
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.