[BUG]: wrong relative paths resolution in `PPME_SYSCALL_LINKAT_2_X`

[Andreagit97]

Describe the bug

Some filter checks don't correctly resolve relative paths for PPME_SYSCALL_LINKAT_2_X event. As you can see in the below definition when oldpath is relative, it should be interpreted relative to the directory referred to by the file descriptor olddir (rather than relative to the current working directory of the calling process).

[PPME_SYSCALL_LINKAT_2_X] = {"linkat", EC_FILE | EC_SYSCALL, EF_NONE, 6, {{"res", PT_ERRNO, PF_DEC}, {"olddir", PT_FD, PF_DEC}, {"oldpath", PT_FSRELPATH, PF_NA, DIRFD_PARAM(1)}, {"newdir", PT_FD, PF_DEC}, {"newpath", PT_FSRELPATH, PF_NA, DIRFD_PARAM(3)}, {"flags", PT_FLAGS32, PF_HEX, linkat_flags} } },

In some filter checks like fs.path.source we resolve the path relative to the current thread working directory rather than resolving the path relative to the olddir.

How to reproduce

TEST_F(sinsp_with_test_input, FS_FILTER_path_resolution_for_linkat)
{
	add_default_init_thread();

	open_inspector();

	int64_t retval_suc = 0;

	/* We generate a `dirfd` that we will reuse with linkat */
	int64_t dirfd = 3;
	const char *dir = "/tmp/example_dir/";
	add_event_advance_ts(increasing_ts(), INIT_TID, PPME_SYSCALL_OPEN_E, 3, dir, 0, 0);
	add_event_advance_ts(increasing_ts(), INIT_TID, PPME_SYSCALL_OPEN_X, 6, dirfd, dir, 0, 0, 0, (uint64_t) 0);

	add_event_advance_ts(increasing_ts(), INIT_TID, PPME_SYSCALL_LINKAT_2_E, 0);	
	auto evt = add_event_advance_ts(increasing_ts(), INIT_TID, PPME_SYSCALL_LINKAT_2_X, 6, retval_suc, dirfd, "some_oldpath", dirfd, "some_newpath", (uint32_t) 0);
	
	ASSERT_FALSE(field_has_value(evt, "fs.path.name")); // This seems coherent with the code but we need to tell users to not use this field with link-like events
	ASSERT_FALSE(field_has_value(evt, "fs.path.nameraw"));

	ASSERT_EQ(get_field_as_string(evt, "fs.path.source"), "/tmp/example_dir/some_oldpath"); // This will return instead `/root/some_newpath` where `/root` is the current working directory of the init thread
	ASSERT_EQ(get_field_as_string(evt, "fs.path.sourceraw"), "/tmp/example_dir/some_oldpath");

	ASSERT_EQ(get_field_as_string(evt, "fs.path.target"), "/tmp/example_dir/some_newpath");
	ASSERT_EQ(get_field_as_string(evt, "fs.path.targetraw"), "/tmp/example_dir/some_newpath");
}

I think that other events are affected by the same issue, but we need to double-check

Moreover looking at the code:

	m_source_checks->emplace(PPME_SYSCALL_LINKAT_2_X, evt_arg_newpath);
	m_target_checks->emplace(PPME_SYSCALL_LINKAT_2_X, evt_arg_oldpath);

source should be evt_arg_oldpath or am i missing something?

[incertum]

Let us check. There was some discussion going on here https://github.com/falcosecurity/libs/issues/1134#issuecomment-1593459072.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[Andreagit97]

/remove-lifecycle stale

[jasondellaluce]

cc @mstemm