[Thinlinc-technical] audit issue

[vlad f halilov]

This  did not call any visible problem without audit (just some higher 
cpu usage and context switching, but user/admin can't see that without 
load profiling). Problem appeared with auditd enabled, because this 
activity produce many records in audit journal, that lead to free disk 
space consumption. For example. system with two idle users generate 
about ~1000 audit events/second like above (Every access to proc, cause 
3 audit event in journal), that about 240K/sec free space out.

Below an strace block for Xvnc process, may be it help? There are two 
'open' syscall to proc, after getsockopt.

...
select(256, [0 1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 
24 25 26 27 28 29 30 31 32 34 36 37], [30],
  NULL, {39, 991000}) = 2 (in [0 36], left {39, 990992})
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, 
NULL) = 0
read(36, "\210\0\2\0\1\0\0\0", 4096)    = 8
read(36, 0x16908e0, 4096)               = -1 EAGAIN (Resource 
temporarily unavailable)
writev(36, 
[{"\1\1\6\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 
32}], 1) = 32
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
accept(0, {sa_family=AF_FILE, NULL}, [2]) = 33
fcntl(33, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(33, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
getsockopt(33, SOL_SOCKET, SO_PEERCRED, "g\n\0\0\364\1\0\0\364\1\0\0", 
[12]) = 0
open("/proc/2663/cmdline", O_RDONLY)    = 35
read(35, "metacity\0", 4097)            = 9
close(35)                               = 0
select(256, [0 1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 
24 25 26 27 28 29 30 31 32 33 34 36 37], [30], NULL, {39, 981000}) = 4 
(in [0 23 33 36], left {39, 980992})
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, 
NULL) = 0
read(23, "(\0\4\0|\315U\2\354\0\0\0\0\0\31\0", 4096) = 16
read(23, 0x1efeae0, 4096)               = -1 EAGAIN (Resource 
temporarily unavailable)
writev(23, 
[{"\1\1\206\5\0\0\0\0\306\345\r\1\362\0Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 
32}], 1) = 32
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
accept(0, {sa_family=AF_FILE, NULL}, [2]) = 35
fcntl(35, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(35, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
getsockopt(35, SOL_SOCKET, SO_PEERCRED, "\371F\0\0\364\1\0\0\364\1\0\0", 
[12]) = 0
open("/proc/18169/cmdline", O_RDONLY)   = 38
read(38, "/usr/bin/gpk-update-icon\0", 4097) = 25
close(38)                               = 0
select(256, [0 1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 
24 25 26 27 28 29 30 31 32 33 34 35 36 37], [30], NULL, {39, 966000}) = 
4 (in [23 33 35 36], left {39, 965987})
...

> I have no experience in kernel auditing and my collegues who probably
> do are away on vacation at the moment.
> But as far as I can see, this is not an issue we have seen before. I do
> not know what can be causing it. Does these cmdline calls cause high
> load or any other problems?
>
> Regards,


-- 
vlad f halilov
swemel