cgroup: enable write permission for the group of users
PATCH 1/1 cgroup: enable write permission for the group of users
Hello,
Working in a development that uses control groups and libcgroup, I have found that the files in control groups directories need write permission for the group of users also.
In example,
here is an excerpt of the configuration of libcgroup, from file "/etc/cgconfig.conf"
******** BEGIN OF EXCERPT
group realtime {
perm {
task {
uid = root;
gid = audio;
}
admin {
uid = root;
gid = jobadmin;
}
}
cpu {
cpu.policy = 1;
cpu.shares = 800;
cpu.rt_runtime_us = 900000;
}
memory {
memory.swappiness = 10;
}
}group usr {
....
}
# batch processes
group usr/batch {
perm {
task {
uid = root;
gid = users;
}
admin {
uid = root;
gid = jobadmin;
}
}
cpu {
cpu.policy = 3;
cpu.shares = 400;
}
memory {
memory.swappiness = 60;
}
}
******* END OF EXCERPTIn cgroup "realtime" We obtain from this configuration that the user "root" is the owner of the cgroup's files, the admins are users in the "jobadmin" group and the users are the "audio" group.
the users that are members of group audio must have write permission to the tasks file to add jobs to this cgroup. And the members of group jobadmin need write permission to the cgroup control files.
Here is attached a near trivial patch to enable it. ******** BEGIN OF PATCH
kernel/cgroup.c +1 -1
@@ -1441,7 +1441,7 @@ static int cgroup_set_super(struct superstatic int cgroup_get_rootdir (struct super_block *sb) {struct inode *inode = -cgroup_new_inode (S_IFDIR |S_IRUGO |S_IXUGO |S_IWUSR , sb); + cgroup_new_inode(S_IFDIR | S_IRUGO | S_IXUGO | S_IWUSR | S_IWGRP,
sb);
struct dentry *dentry;
if (!inode)
@@ -2265,9 +2265,9 @@ static int cgroup_create_dir(struct cgro
* @cft: the control file in question
*
* returns cft->mode if ->mode is not 0
- * returns S_IRUGO|S_IWUSR if it has both a read and a write handler
+ * returns S_IRUGO|S_IWUSR|S_IWGRP if it has both a read and a write handler
* returns S_IRUGO if it has only a read handler
- * returns S_IWUSR if it has only a write hander
+ * returns S_IWUSR|S_IWGRP if it has only a write hander
*/
static mode_t cgroup_file_mode(const struct cftype *cft)
{
@@ -2281,8 +2281,10 @@ static mode_t cgroup_file_mode(const str
mode |= S_IRUGO;
if (cft->write || cft->write_u64 || cft->write_s64 ||
- cft->write_string || cft->trigger)
+ cft->write_string || cft->trigger) { mode |= S_IWUSR;
+ mode |= S_IWGRP;
+ }
return mode;
}
@@ -3244,7 +3246,7 @@ static struct cftype files[] = {
.open = cgroup_tasks_open, .write_u64 = cgroup_tasks_write, .release = cgroup_pidlist_release,
- .mode = S_IRUGO | S_IWUSR,
+ .mode = S_IRUGO | S_IWUSR | S_IWGRP,
},
{
.name = CGROUP_FILE_GENERIC_PREFIX "procs",
******** END OF PATCH
see a more complete explanation of the development and the related code in following URL.
http://livenet.selfip.com/?content=06utilitats-Ccgroups
http://livenet.selfip.com/ftp/debian/cgroups-daemon/
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
cgroup: Add write permission for the group of users.
kernel/cgroup.c +7 -5
@@ -1441,7 +1441,7 @@ static int cgroup_set_super(struct superstatic int cgroup_get_rootdir (struct super_block *sb) {struct inode *inode = -cgroup_new_inode (S_IFDIR |S_IRUGO |S_IXUGO |S_IWUSR , sb); +cgroup_new_inode (S_IFDIR |S_IRUGO |S_IXUGO |S_IWUSR |S_IWGRP , sb);struct dentry *dentry;if (!inode)
@@ -2265,9 +2265,9 @@ static int cgroup_create_dir(struct cgro* @cft: the control file in question * * returns cft->mode if ->mode is not 0 -* returns S_IRUGO|S_IWUSR if it has both a read and a write handler +* returns S_IRUGO|S_IWUSR|S_IWGRP if it has both a read and a write handler * returns S_IRUGO if it has only a read handler -* returns S_IWUSR if it has only a write hander +* returns S_IWUSR|S_IWGRP if it has only a write hander */ static mode_t cgroup_file_mode (const struct cftype *cft) {
@@ -2281,8 +2281,10 @@ static mode_t cgroup_file_mode(const str mode |=S_IRUGO ;if (cft->write || cft->write_u64 || cft->write_s64 || - cft->write_string || cft->trigger) + cft->write_string || cft->trigger) { mode |=S_IWUSR ; + mode |=S_IWGRP ; + }return mode; }
@@ -3244,7 +3246,7 @@ static struct cftype files[] = { .open = cgroup_tasks_open, .write_u64 = cgroup_tasks_write, .release = cgroup_pidlist_release, - .mode = S_IRUGO | S_IWUSR, + .mode = S_IRUGO | S_IWUSR | S_IWGRP, }, { .name = CGROUP_FILE_GENERIC_PREFIX "procs",
Quoted 5 lines · Jordi Pujol
Hello,
Working in a development that uses control groups and libcgroup, I have found that the files in control groups directories need write permission for the group of users also.
This can be configured from userspace - chmod() works just fine on control files in cgroupfs.
Paul
Quoted 9 lines · Paul Menage
Quoted 5 lines · Jordi Pujol
Hello,
Working in a development that uses control groups and libcgroup, I have found that the files in control groups directories need write permission for the group of users also.
This can be configured from userspace -
chmod()works just fine on control files in cgroupfs.
Sure, many things can be worked around in user-space, but the question is, does the +g make sense as default cgroupfs permissions?
Thanks,
Ingo
Quoted 3 lines · Ingo Molnar
Sure, many things can be worked around in user-space, but the question is, does the +g make sense as default cgroupfs permissions?
It's certainly arguable that group-writable permissions might have made sense as the default when cgroupfs was first introduced. I don't particularly think there was a strong argument either way, and this was one of the semantics that was inherited from cpusets to simplify backwards-compatibility.
But given the current default file mode, and given than the default gid for a cgroupfs file is 0, any cgroups controller in user-space that wants to make it group-accessible needs to chown() the file to set the group appropriately. So doing an additional chmod() is really no significant amount of extra work/code. Since any kernel from the last four years will have cgroupfs files that default to mode 644, even if we change the default mode to 664 said controller will need to include the chmod code in case it's running on an older kernel. So I don't see a real benefit in changing the default, and there's always the slight change of introducing a security hole in a controller that assumes the 644 default.
Paul
agree, thanks for your replies,
To be polite, for if any user finds this thread, here is a solution, the code added to the daemon script
set_writeperm_usergroups() {
local mountpoint f st_mode
mountpoint="$(awk '$1 == "cgroup" {print $2}' "/proc/mounts")"
if [ ! -d "${mountpoint}" ]; then
log_warning_msg "Can't find cgroups mountpoint"
return
fi
while read f; do
if st_mode="0x$(stat --format='%a' "${f}")" && \
[ $((${st_mode} & 0x20)) -eq 0 ]; then
chmod g+w "${f}"
fi
done << EOF$(find "${mountpoint}" -type f -perm '-u=w')
EOF
}
Regards,
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
Quoted 9 lines · Ingo Molnar
Quoted 7 lines · Paul Menage
Quoted 5 lines · Jordi Pujol
Hello,
Working in a development that uses control groups and libcgroup, I have found that the files in control groups directories need write permission for the group of users also.
Quoted 5 lines
Quoted 2 lines
This can be configured from userspace -
chmod()works just fine on control files in cgroupfs.Sure, many things can be worked around in user-space, but the question is, does the +g make sense as default cgroupfs permissions?
I don't think this is anything the kernel can guess, the cgroup filesystem is root only on initial mount time for a good reason. Anything thereafter is purely up to userspace.