On 04.05.2023 00:27, Paul Moore wrote:
On Wed, May 3, 2023 at 5:14 PM Rinat Gadelshin <rgade...@gmail.com> wrote:
Hello there =)
My name is Rinat.
I'm a newbie here (at Linux kernel developer community).
My current job is to work with audit subsystem on different
versions of Linux (and different kernel versions from 3.10 to the latest)
with and without auditd.
My program works behalf of root account and uses netlink
(unicast or multicast depends of the kernel's version)
to communicate with audit subsystem of the kernel.
If actual audit rule list has been changed
then my program should restore the configured audit rule list.
To do it the program periodically (with 60 seconds interval)
requests the actual rule list be sending AUDIT_LIST_RULES.
All rules are receiving perfectly.
But I've noticed that there are many (2K+ for 5 minutes test)
kthreadd process have been spawned after that request
(I've stubbed the poll code and compare logs).
Hi Rinat,
First, a quick note that audit discussions involving the upstream
Linux Kernel have moved to the au...@vger.kernel.org list (CC'd),
please direct future emails there.
Can you be more specific about the kernel threads you are seeing, are
you seeing multiple "kauditd" threads?
% ps -fC kauditd
UID PID PPID C STIME TTY TIME CMD
root 89 2 0 Apr28 ? 00:00:00 [kauditd]
Please, can you point me, what can I do to avoid this kthreadd-spam.
Thank you.
Best regards
Rinath
Hi Paul,
Thank you for your quick answer.
I swear to copy my future questions about audit subsystem to
au...@vger.kernel.org =)
My logs don't provide lot of info about nature of the kthreadds.
(I hadn't written the log system).
I have something like this:
...pid: 2, uniquePid: 000082d800000002, fileName: kthreadd, lcFileName:
kthreadd, name: kthreadd, commandLine: Skipped, lcCommandLine: Skipped,
sessionId: 0, isRemote: 0, syscallName: fork, uid: 4294967295, gid:
4294967295, euid: 4294967295, egid: 4294967295, logonSessionUid: -1,
logonSessionUsername: Skipped, logonSessionRemoteHost: , exeOwnerUid: 0,
exeOwnerGid: 0, exeMode: 0, exeInode: 0, exeCapsVersion: ,
exeCapsRootId: , exeCapsEffective: , exeCapsPermitted: ,
exeCapsInheritable: , dstPid: 106574, dstTid: 0, dstUniquePid:
000083b10001a04e, requestId: 2684354949, startTime: 01d97d1fb24aa38e,
hash: 00000000000000000000000000000000, cwd: , flags: 00000011,
processState: 3, int: 0, type: 00000000..
And such events occurred 1208 times when AUDIT_LIST_RULES is sending.
The test has lasted 2 minutes.
The same test in which the request was disabled produced only 122 such
records.
It was the only difference between the tests.
As I can see it was a fork syscall of kthreadd.
Are there any debug options for the kernel that I can set, rebuild the
kernel, re-run the test and clarify the situation?
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
