On Thu, May 07, 2015 at 11:32:26AM +0300, Vladimir Davydov wrote:
> On Thu, May 07, 2015 at 10:51:16AM +0300, Cyrill Gorcunov wrote:
> > Index: linux-pcs7.git/kernel/cgroup.c
> > ===================================================================
> > --- linux-pcs7.git.orig/kernel/cgroup.c
> > +++ linux-pcs7.git/kernel/cgroup.c
> [...]
> > @@ -1668,6 +1617,17 @@ static struct dentry *cgroup_mount(struc
> >
> > BUG_ON(sb->s_root != NULL);
> >
> > +#ifdef CONFIG_VE
> > + /*
> > + * Don't allow to create new hierarchies in container,
> > + * we don't support them.
> > + */
> > + if (!ve_is_super(get_exec_env())) {
> > + ret = -EACCES;
> > + goto drop_new_super;
> > + }
> > +#endif
>
> So we are not allowed to create new cgroup hierarchies from a container,
> but we still can mount existing ones? If so, I think we should forbid
> this either.
Yes existing ones are not forbidden. I'm not sure though if we should
not allow to reuse existing hierarchies. You have some secutiry scenario
in your mind or mean to make everything as strict as possible until
the reverse is not explicitly needed?
> Another question that keeps bothering me is about permissions check. The
> admin of a container should be allowed to create and tune memory cgroups
> under its bind mounted cgroup root, but he must not be able to modify
> parameters of the bind mounted root itself, because that would affect
> the container's configuration. How are we going to prevent this?
At moment we don't, but looks like we need to add some check if
cgroup been modified is not a top one when write happens from
inside of container maybe?
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
