Skip to contentSkip to conversation

cgroup: enable write permission for the group of users

PATCH In review Jordi Pujol 4 participants 6 messages Feb 1, 2011 – Feb 2, 2011

lore
Share & tools
lore
#0 lore raw

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 EXCERPT

In 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 super
 static 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 super
 static 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",
#1 lore raw
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

#2 lore raw
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

#3 lore raw
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

#4 lore raw

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

#5 lore raw
In reply to Ingo Molnar
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.