Hi,
Dhaval Giani wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> * Think about the length of process name.
>>>>>>>> A process name is taken from /proc/<pid>/status file, and the name
>>>>>>>> is shortened to 15 characters if the real name is over than 16
>>>>>>>> characters. That is a linux kernel's behavior. Should we consider
>>>>>>>> a process name in /etc/cgrules.conf as 15 characters, if it is over
>>>>>>>> than 16 characters like a linux kernel ?
>>>>>>>>
>>>>>>> I'm sorry that I don't read the whole patch precisely.
>>>>>>>
>>>>>>> Why based on "process name", why not "exec file" ?
>>>>>>> Do you have special reason ?
>>>>>> One disadvantage of exe file I can think of is "script" file.
>>>>>> But /proc/xxx/status's information is too naive.
>>>>>>
>>>>>> Can't you parse /proc/xxx/cmdline file and check "what's really executed
>>>>>> ?"
>>>>>> Parser can be very difficult ?
>>>>> Good point. We can parse /proc/xxx/cmdline instead of /proc/xxx/status
>>>>> for getting a process name, and that is better than current patch.
>>>>> But I have one concern. The /proc/xxx/cmdline file of a kernel thread is
>>>>> empty, and we cannot get the name from the file.
>>>>> How about getting a process name from a /proc/xxx/status file only if
>>>>> /proc/xxx/cmdline is empty ?
>>>>>
>>>> Maybe good. For example, "ps" does [kthread] for tasks with empty cmdline.
>>>>
>>>> But, IIUC, a script like
>>>>
>>>> %./myscript.sh
>>>>
>>>> has cmdline as /bin/bash ./myscript.sh and "status" file includes
>>>> "myscript.sh"
>>>> So, there may be 3 ways for specifing a task by name.
>>>>
>>>> exe:/bin/bash # full-path name of executable file (but can't
>>>> handle scripts)
>>>> comm:myscript.sh # name of executable file
>>>> cmdline:/bin/bash myscript.sh # cmdline
>>>>
>>>> Then, having "exe" and "comm" is maybe good....maybe.
>>> I guess you means the following, right ?
>>>
>>> * libcgroup should distinguish "exec file" or "script file" of each
>>> process automatically.
>>>
>>> * If "exec file", the first arg in /proc/<pid>/cmdline is checked.
>>> In your example, the first arg means /bin/bash.
>>>
>>> * If "script file", the item of "Name:" in /proc/<pid>/status is checked.
>>> In your example, the item means myscript.sh.
>>>
>> I have no objections if we have clear rule.
>> If I was you, I'll write following logic.
>>
>> NEW) <user>:(<ops>=):<process name> <controllers> <destination>
>>
>> ops can be "exe", "comm", "cmdline"
>>
>> exe=/bin/bash
>> or
>> comm=myscript.sh
>> or
>> cmdline="/bin/bash /home/kamezawa/bin/myscript.sh"
>>
>> Complicated ?
>
> Quite complicated actually. What this would mean is that we would also
> need some tool which could write the config files out. I am not sure if
> this is the way we want to proceed forward in.
>
>> I have no strong opinion but I feel only "comm" can be too short for
>> enterprise users. I saw 3 version of "java" runs under different applications
>> in user's environment, all uid were "root". (oh, yes, seems crazy ;)
>>
>
> True, but I think we need to keep the configuration file as simple as
> possible for it to be useful.
I have a little headache, and I'd like to clarify some requests.
1) Handle a shell process by a rule based on shell name. (KAMEZAWA)
2) Handle a process by a rule based on full path of command. (KAMEZAWA)
3) Keep the configuration file as simple as possible. (Dhaval)
I feel it is better that a process name is taken from /proc/<pid>/status
without parsing /proc/<pid>/cmdline now, sorry for my mind change.
/proc/<pid>/cmdline can be changed by an application, so I feel that is
not enough for the key of rules. The following is an example:
===================================================================
$ cat change_arg.c
#include <stdio.h>
#include <string.h>
main(int argc, char *argv[])
{
int i;
printf("argv[0] = %s\n", argv[0]);
memset(argv[0], '*', strlen(argv[0]));
while(1);
}
$ gcc -o change_arg change_arg.c
$ ./change_arg &
[1] 7727
argv[0] = ./change_arg
$
$ cat /proc/7727/cmdline
************$
$
$ grep Name: /proc/7727/status
Name: change_arg
$
===================================================================
On the other hand, the item "Name:" of /proc/<pid>/status presents the
real name of a process and it is good for the key.
In addition, the item "Name:" presents a shell script name, not a shell
command name. That matches the request 1).
$ ./loop.sh &
[1] 7763
$ cat /proc/7763/cmdline
/bin/bash./loop.sh$
$ grep Name: /proc/7763/status
Name: loop.sh
$
Also, a rule based on the item "Name:" keeps the configuration file
simple like the following. (request 3)
NEW RULE (/etc/cgrules.conf):
=============================
EXISTING) <user> <controllers> <destination>
NEW) <user>:<process name> <controllers> <destination>
A rule based on the item "Name:" doesn't match request 2). But I
feel we will implement it in future, when we need it really.
The item "Name:" has only 15 characters, but it is enough in many
cases.
Thanks
Ken'ichi Ohmichi
------------------------------------------------------------------------------
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
