On Thu 19-05-11 14:01:29, Jan Safranek wrote: > On 05/19/2011 11:23 AM, Michal Hocko wrote: > > On Tue 17-05-11 12:57:11, Jan Safranek wrote: > >> On 05/16/2011 02:07 PM, Michal Hocko wrote: > > [...] > >>> The patch checks whether uid differs from gid either for task or admin > >>> and automatically changes the file and directory permissions to be user > >>> and group read&write (and executable for directories). > >> > >> Why is gid and uid compared together? These two number have nothing in > >> common! > >> > >>> The proper fix for this would be to enable file and directory permissions > >>> setting in configuration file but let's do it later. > >> > >> Well, fa3d180b is there for a reason, adding 664 everywhere will break > >> e.g. cgsnapshot. Some parameters are meant only for writing, typically > >> devices.allow/deny. If you want to fix it properly, then copy user's > >> permissions to group, i.e. from > >> --w-------. 1 root root 0 2010-11-02 08:04 devices.allow > >> to > >> --w--w----. 1 root root 0 2010-11-02 08:04 devices.allow > > > > I have just checked cgcreate and it doesn't take care about the original > > file permissions as well: > > With -f you explicitly tell what permissions you want there, libcgroup > does not check/copy anything. Maybe this could be changed to > umask-style, where -f XYZ would represent maximum permissions and actual > permissions would be determined from owner's. > > I.e. with -f 775, one would get > --w--w----. 1 root root 0 May 19 13:54 cgroup.event_control > -r--r--r--. 1 root root 0 May 19 13:54 cgroup.procs > -rw-rw-r--. 1 root root 0 May 19 13:54 tasks > > And with -f 750: > --w-------. 1 root root 0 May 19 13:54 cgroup.event_control > -r--r-----. 1 root root 0 May 19 13:54 cgroup.procs > -rw-r-----. 1 root root 0 May 19 13:54 tasks > > Would this be acceptable solution?
Sure, sounds good. I will do it that way in the patchset for permission setting in configuration file. > > > > > > # cgcreate -a root:cgroup -f 775 -g cpu:foo > > foo# ls -l > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 cgroup.clone_children > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 cgroup.event_control > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 cgroup.procs > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 cpu.rt_period_us > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 cpu.rt_runtime_us > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 cpu.shares > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 notify_on_release > > -rwxrwxr-x 1 root cgroup 0 May 19 11:17 tasks > > > > while > > --w--w--w- 1 root root 0 May 19 11:19 cgroup.event_control > > > > So the workaround doesn't break more that we already do with > > cgcreate. Obviously both need a better way of permissions handling. > > My libcgroup-0.37.1 creates the group with > -rwxrwxr-x. 1 root cgroup 0 May 19 13:49 cgroup.event_control Sorry, this was probably confusing. These are original permisions if I just create the group by mkdir. -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
