Dhaval Giani wrote: > On Fri, May 29, 2009 at 10:57:41AM +0200, Jan Safranek wrote: >> Ken'ichi Ohmichi wrote: >>> Hi Jan, >>> >>> Jan Safranek wrote: >>>> Ken'ichi Ohmichi wrote: >>>>> Hi, >>>>> >>>>> This patchset adds a new rule based on process name. >>>>> I have some TODOS, so this patchset is not complete. >>>>> I'd like to talk about them, any comment is welcome. >>>>> >>>>> TODOS: >>>>> ====== >>>>> * The cgroup directory, which is specified by `cgexec` command, is >>>>> ignored because this patch adds an EXEC event to the event handler. >>>>> This problem should be fixed. >>>> Not only this, your patchset changes semantic of pid in >>>> cgroup_change_cgroup_uid_gid from 'change this process' to 'change this >>>> process based on its process name'. If one has following cgrules.conf: >>>> >>>> *:cgexec cpu first >>>> * cpu second >>>> >>>> and executes 'cgexec bash', the first rule is matched instead of the >>>> second one - cgroup_change_cgroup_uid_gid is called with pid of cgexec. >>>> Should there be a new flag in cgroup_change_cgroup_uid_gid_flags, which >>>> would tell it not to use procname? Or use procname provided by caller >>>> (i.e. cgexec would pass 'bash' in this case)? >>> Thank you for good point. >>> I am worried of the coverage of a new rule based on process name. >>> Do you think a new rule should not be applied to cgexec and cgclassify ? >>> I feel it is better that a new rule is applied to all libcgroup tools, >>> because the rule must be the same. >> Yes, the cgruleseng should move also cgclassify and cgexec tools to the >> right group, based on rules. But it should not prevent cgexec to do its >> job - execute one specified task in specified group. >> >> When admin does not use cgrulesengd, 'cgexec bash' should IMHO find >> appropriate rule for process 'bash' and user/group, which is executing >> the cgexec, move its process to appropriate group and execute bash. So, >> it should find rule with 'bash', not with 'cgexec' in the cgred.conf. >> With your patches, it looks for rule with 'cgexec', which is wrong. >> > > I am losing out on something here. But does cgexec not do another > fork+exec and on doing the exec it would be caught again for bash? (I > have not reviewed all the patches yet, so please correct me if I am > wrong)
Yes, cgexec calls exec(), which leads to event in cgrulesengd. It's in the TODO (see above) to force cgexec's group and do not change it again by cgrulesengd (in case someone calls 'cgexec -g some_group bash'). But I wrote that cgrulesengd is not used in my scenario, it is not mandatory to run it, is it? Some people may be happy to use cgexec only. Jan ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
