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
--- linux-2.6.37/kernel/cgroup.c
+++ linux-2.6.37/kernel/cgroup.c 2011-01-30 15:16:00.556562499 +0100
@@ -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
On Tue, Feb 1, 2011 at 1:02 AM, Jordi Pujol <[email protected]> wrote:
> 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
* Paul Menage <[email protected]> wrote:
> On Tue, Feb 1, 2011 at 1:02 AM, Jordi Pujol <[email protected]> wrote:
> > 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
On Tue, Feb 1, 2011 at 5:27 PM, Ingo Molnar <[email protected]> wrote:
>
> 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
On Wed, 2011-02-02 at 02:27 +0100, Ingo Molnar wrote:
> * Paul Menage <[email protected]> wrote:
>
> > On Tue, Feb 1, 2011 at 1:02 AM, Jordi Pujol <[email protected]> wrote:
> > > 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?
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.