On Wed, 27 May 2009 16:06:03 +0900
"Ken'ichi Ohmichi" <[email protected]> wrote:
>
> Hi,
>
> KAMEZAWA Hiroyuki 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 ?
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 ;)
Thanks,
-Kame
------------------------------------------------------------------------------
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
