Draft
Conversation
This is a very basic implementation of inode tracking meant to be used in the upcoming release and improved upon in the near future. The current implementation will perform a scan of the paths that are configured to be monitored, using the inode and device numbers as a key to two maps: - A BPF hash map for kernelspace to know when an inode triggers an event. - A HashMap in userspace that maps the inode to a path that we found the inode at. With these two maps we are able to confidently emit events for files that are mounted into containers with paths that don't necessarily match the prefixes configured for monitoring and, at a later stage in userspace, add the path on the host to the event itself. The implemented approach is far from complete, it will only work as long as the files found during the initial scan are not moved, deleted or replaced by a different file. Future patches will extend the functionality of both kernel and userspace to be able to catch more corner cases.
Added tests will validate events generated on an overlayfs file properly shows the event on the upper layer and the access to the underlying FS. They also validate a mounted path on a container resolves to the correct host path. While developing these tests, it became painfully obvious getting the information of the process running inside the container is not straightforward. Because containers tend to be fairly static, we should be able to manually create the information statically in the test and still have everything work correctly. In order to minimize the amount of changes on existing tests, the default Process constructor now takes fields directly and there is a from_proc class method that builds a new Process object from /proc. Additionally, getting the pid of a process in a container is virtually impossible, so we make the pid check optional.
This patch proposes a simple way of pipelining components. The pattern is to have each new component in the chain take the receiver end of the previous block as part of their builder, having the builder return a tuple with the object and the receiver end of this block, allowing that receiver to be passed to the next block. In this new approach there are two special cases: * The Bpf module starts the chain, so it does not take a receiver. * The output module is the end of the chain, so it does not give a receiver back.
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This patch proposes a simple way of pipelining components. The pattern is to have each new component in the chain take the receiver end of the previous block as part of their builder, having the builder return a tuple with the object and the receiver end of this block, allowing that receiver to be passed to the next block.
In this new approach there are two special cases:
Checklist
Automated testing
If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why you did not do so. (Valid reasons include "CI is sufficient" or "No testable changes")
In addition to reviewing your code, reviewers must also review your testing instructions, and make sure they are sufficient.
For more details, ref the Confluence page about this section.