I just apply the patches and try to test the result and I get segfault:
GNU gdb (GDB) Fedora (6.8.50.20090302-21.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) r less cgexec.c
Starting program: /root/libcg/20090527/s/libcg/src/tools/.libs/lt-cgexec
less cgexec.c
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0xbfffe178 "", src=0x10c <Address 0x10c out of
bounds>) at strcpy.c:39
39 strcpy.c: No such file or directory.
in strcpy.c
Current language: auto; currently minimal
(gdb) bt
#0 *__GI_strcpy (dest=0xbfffe178 "", src=0x10c <Address 0x10c out of
bounds>) at strcpy.c:39
#1 0x006330e2 in cg_prepare_cgroup (cgroup=0xbfffe178, pid=17887,
dest=0x10c <Address 0x10c out of bounds>, controllers=0x110c)
at api.c:1770
#2 0x006335a2 in cgroup_change_cgroup_path (dest=0x10c <Address 0x10c
out of bounds>, pid=17887, controllers=0x110c) at api.c:2041
#3 0x006334c7 in cgroup_change_cgroup_uid_gid_flags (uid=0, gid=0,
pid=17887, flags=0) at api.c:1988
#4 0x00633535 in cgroup_change_cgroup_uid_gid (uid=0, gid=0, pid=17887)
at api.c:2020
#5 0x08048bfc in main (argc=3, argv=0xbffff624) at cgexec.c:109
(gdb)
Dhaval Giani wrote:
> On Wed, May 27, 2009 at 04:37:18PM +0900, KAMEZAWA Hiroyuki wrote:
>
>> 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 ?
>>
>
> 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.
>
> Thanks,
>
------------------------------------------------------------------------------
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
