Closed araujof closed 2 years ago
Hey @araujof thank you for pointing this out! For what concern the execveat
exit event, this is the normal kernel behavior, since execveat
is a wrapper of execve
, when the call succeeds the event returned is simply an execve
exit event. Only in case of syscall failure we can observe an execveat
exit event... you can find more information in this PR, where the support for execveat
was introduced.
The exepath
issue is new to me, so I need to take a closer look at it :eyes: thank you again for having highlighted it!
@Andreagit97 Thanks for getting back to me quickly and pointing to the PR :)
Ei @araujof this PR https://github.com/falcosecurity/libs/pull/552 should solve the issue, I have added some test cases and it seems to work smooth :)
@Andreagit97 thanks a bunch! We will test.
@Andreagit97 I tested PR #552 with the program example above, and it solves the exepath
issue. Below is a SysFlow trace showing the correct exepath
's (Cmd
field). Thanks!
Describe the bug
In our tests of several versions of the libs between 0.31.1 and 0.32.1 (inclusive), we ~observed that the execveat system call exit is propagating to libsinsp as execve (ev->get_type() returns 293 instead of 331). We also~ noticed that m_exepath is miscalculated, while m_exe is correct. This is observed from live captures with eBPF/kmod drivers and pre-recorded scap file.
How to reproduce it
To reproduce, compile the following code:
From the latest release of sysdig (0.29.3):
Printing the values directly from the sinsp event's exit, we get:
Expected behavior
~The event type (as returned by ev->get_type()) should be 331 (denoting execveat) on exit. Also,~ m_exepath should be "/bin/echo" in this example code.
Environment