libcg.git/src, branch review/daemon-exec

Hi,

2009-05-26T13:10:04+00:00

A process name is changed when execve(2), so a new rule based on
process name should be applied when execve(2) happens.
Then this patch adds an EXEC event to the event handler.

TODO:
=====
* 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.


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi

Hi,

2009-05-26T13:09:03+00:00

This patch adds the key "process name" to find a matching rule.

By this patch, cgroup_change_cgroup_uid_gid_flags() gets a process
name by the parameter "pid" internally and uses it to find a matching
rule.


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi

Hi,

2009-05-26T13:08:59+00:00

This patch adds the parser of process name in /etc/cgrules.conf.

A new rule based on process name is as the following, and the process
name is stored into the member "procname" in struct cgroup_rule.
  :     


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi

Hi,

2009-05-26T13:08:43+00:00

There are some similar functions for getting process's data (uid,
gid) from /proc//status file, so this patch integrates these
functions into one cgroup_get_procdata_from_status().
In addition, cgroup_get_procdata_from_status() can get also a
process name from /proc//status file.


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi

Hi,

2009-05-26T12:52:42+00:00

To add the member "procname" to struct cgroup_rule by later patch, this
patch renames the member "name" to "username" for the clarification.


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi

Hi,

2009-05-26T12:52:42+00:00

The loop in cgroup_parse_rules() is a little long now, and it is not
easy to read the loop.
Then, This patch shortens the loop for the readability.


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi

Hi,

2009-05-26T12:52:42+00:00

By using sizeof() in memset(), we will not need to care of the buffer
size.


Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi

Fix the deadlock of rl_lock.

2009-05-22T09:16:22+00:00

Hi,

Changelog of v2:
  - Add the description of the problematic call sequence.
  - There is not any change in the code.

[PATCH-v2] Fix the deadlock of rl_lock.

For avoiding the deadlock, protect cdgroup_change_cgroup_uid_gid_flags()
by blocking SIGUSR2 signal.

The problematic call sequence is the following:
----------------------------------------------------------------------
* CGRULESENGD DAEMON *
  << cgre_flash_rules() is the signal handler for SIGUSR2 signal >>
  cgre_create_netlink_socket_process_msg()
    << Receive a UID/GID event packet >>
    cgre_handle_msg()
      cgre_process_event()
        cgroup_change_cgroup_uid_gid_flags()
          cgroup_find_matching_rule_uid_gid()
            pthread_rwlock_wrlock(&rl_lock);  << Get the lock of rl_lock >>
            << Receive a SIGUSR2 signal, and switch to cgre_flash_rules() >>
  cgre_flash_rules()
    cgroup_reload_cached_rules()
      cgroup_parse_rules()
        pthread_rwlock_wrlock(&rl_lock);  << deadlock ! >>
----------------------------------------------------------------------

A cgrulesengd daemon needs a lock of rl_lock for referring configuration
buffer. On the other way, the daemon reloads configuration file when
receiving SIGUSR2 signal, and it needs the same lock in cgroup_parse_rules().
So cgroup_change_cgroup_uid_gid_flags() should be protected from SIGUSR2
signal for avoiding the deadlock.

Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi 
Signed-off-by: Dhaval Giani

Fix the deadlock of vsyslog() call.

2009-05-22T09:16:21+00:00

Hi,

I found the deadlock problem that a cgrulesengd daemon stalls if
service "cgred" is reloaded while many UID events happen.
The following is the gdb output by attaching the stalling daemon:

 (gdb) bt
 #0  0x0000003b298dd918 in __lll_mutex_lock_wait () from /lib64/libc.so.6
 #1  0x0000003b298ce847 in _L_lock_646 () from /lib64/libc.so.6
 #2  0x0000003b298ce2da in __vsyslog_chk () from /lib64/libc.so.6
 #3  0x0000000000401533 in flog (level=5, format=0x402778 "Reloading rules configuration.") at cgrule sengd.c:130
 #4  0x00000000004015d1 in cgre_flash_rules (signum=) at cgrulesengd.c:644
 #5  
 #6  0x0000003b298d27b5 in send () from /lib64/libc.so.6
 #7  0x0000003b298ce3a0 in __vsyslog_chk () from /lib64/libc.so.6
 #8  0x0000000000401533 in flog (level=4, format=0x402b82 "Failed to open %s") at cgrulesengd.c:130
 #9  0x0000000000401cc7 in cgre_process_event (ev=0x7fff8ad11cc4, type=4) at cgrulesengd.c:161
 #10 0x0000000000401fd5 in cgre_create_netlink_socket_process_msg () at cgrulesengd.c:486
 #11 0x00000000004023ca in main (argc=1, argv=) at cgrulesengd.c:878
 (gdb)

We can see __vsyslog_chk() is called twice, because the daemon
recieved a SIGUSR2 signal in __vsyslog_chk(). In __vsyslog_chk(),
"syslog_lock" is locked by __libc_lock_lock(syslog_lock).
So I think vsyslog() should be protected by blocking the signal,
and this patch fixes the problem by doing it.

Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi 
Signed-off-by: Dhaval Giani

Cleanup the infinite loop of cgrulesengddaemon.

2009-05-19T03:05:22+00:00

Hi,

This patch clarifies the infinite loop.

Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi 
Acked-by: Balbir Singh 
Acked-by: Dhaval Giani