Conversation
2b26cf5 to
90639bf
Compare
Codecov Report❌ Patch coverage is ❌ Your patch status has failed because the patch coverage (50.81%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## master #2864 +/- ##
============================================
- Coverage 78.36% 78.23% -0.14%
Complexity 2526 2526
============================================
Files 173 173
Lines 18742 18742
Branches 976 981 +5
============================================
- Hits 14688 14662 -26
- Misses 3517 3540 +23
- Partials 537 540 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
058b09e to
8cb68ab
Compare
f7f901d to
a231e58
Compare
257c19e to
e4b4417
Compare
a231e58 to
9572bea
Compare
e4b4417 to
def357c
Compare
7d954a5 to
01b184e
Compare
fcf2f95 to
4e538d5
Compare
b83fda5 to
e86dbb8
Compare
6805e43 to
30a3015
Compare
f68263b to
e909749
Compare
ef4fdab to
4c61ac8
Compare
Anilm3
left a comment
There was a problem hiding this comment.
Still reviewing and testing, so far:
Some configurations are being ignored but I haven't checked why:
Ignoring config with key employee/ASM_DD/29.recommended.json/config; unsupported product
The capabilities are not correct, the list should be:
ASM_ACTIVATION
ASM_EXCLUSIONS
ASM_CUSTOM_BLOCKING_RESPONSE
ASM_REQUEST_BLOCKING
ASM_RESPONSE_BLOCKING
ASM_CUSTOM_RULES
ASM_TRUSTED_IPS
ASM_DD_RULES
ASM_IP_BLOCKING
ASM_USER_BLOCKING
And updates seem to performed on every poll even if no changes have been made to the actual configurations.
| { | ||
| auto common = std::atomic_load(&common_); | ||
| common->subscribers.emplace_back(sub); | ||
| common_->subscribers.emplace_back(std::move(sub)); |
There was a problem hiding this comment.
Are you sure removing the std::atomic_load doesn't create a race condition?
If multiple threads of execution access the same std::shared_ptr object without synchronization and any of those accesses uses a non-const member function of shared_ptr then a data race will occur unless all such access is performed through these functions, which are overloads of the corresponding atomic access functions (std::atomic_load, std::atomic_store, etc.).
There was a problem hiding this comment.
Subscription is effectively part of the engine creation (in engine::from_settings), so this is not a problem. common_->subscribers is effectively final. What is changed on engine update is actually common_, at that one is updated atomically in engine::update.
| } | ||
|
|
||
| engine::ptr engine::from_settings(const dds::engine_settings &eng_settings, | ||
| std::unique_ptr<engine> engine::from_settings( |
There was a problem hiding this comment.
This is confusing, albeit not incorrect as far as I can tell, the engine is used as a shared_ptr but you return a unique_ptr.
There was a problem hiding this comment.
The function of engine::from_settings is to create an engine and give ownership to the caller. If the instance will have shared ownership afterwards doesn't really concern this factory method.
| public: | ||
| explicit product(std::string_view name, listener_base::shared_ptr listener) | ||
| : name_(name), listener_(std::move(listener)) | ||
| explicit constexpr product(std::string_view name) : name_{name} {} |
There was a problem hiding this comment.
At this point...
using product = std::string_view;
There was a problem hiding this comment.
AFAIC the alias vs newtype debate is conclusively settled :)
| echo datadog.appsec.helper_path=/appsec/libddappsec-helper.so | ||
| echo datadog.appsec.helper_log_file=/tmp/logs/helper.log | ||
| echo datadog.appsec.helper_log_level=info | ||
| # echo datadog.appsec.helper_log_level=debug |
There was a problem hiding this comment.
should this be not commented out?
There was a problem hiding this comment.
Unfortunately debug is too verbose because of the WAF. It's good for debugging, but not more normal tests runs I think.
| } | ||
|
|
||
| [[nodiscard]] protocol::get_configs_request client::generate_request() const | ||
| bool client::poll() |
There was a problem hiding this comment.
Maybe I missed it but is there any tests on helper tests checking this? I saw the client_test got removed
There was a problem hiding this comment.
You're right, I removed it. These are tested only on the integration tests. Reading of remote config is done by calling ddog_remote_config_read, which is a function implemented in Rust that we import.
Any test using the real Rust read function would writing in shared memory in the format expected by that rust code. By that time, we're having the test depend on implementation details of the rust code.
And by mocking ddog_remote_config_read, we're testing much useful stuff anymore.
8d142c2 to
708dbe4
Compare
Benchmarks [ tracer ]Benchmark execution time: 2024-10-07 18:06:29 Comparing candidate commit 1856dd0 in PR branch Found 4 performance improvements and 0 performance regressions! Performance is the same for 174 metrics, 0 unstable metrics. scenario:ContextPropagationBench/benchInject64Bit-opcache
scenario:SamplingRuleMatchingBench/benchRegexMatching3-opcache
scenario:SamplingRuleMatchingBench/benchRegexMatching4
scenario:TraceFlushBench/benchFlushTrace
|
Benchmarks [ appsec ]Benchmark execution time: 2024-10-07 18:13:46 Comparing candidate commit 1856dd0 in PR branch Found 0 performance improvements and 3 performance regressions! Performance is the same for 9 metrics, 0 unstable metrics. scenario:LaravelBench/benchLaravelOverhead-appsec
scenario:SymfonyBench/benchSymfonyOverhead-appsec
scenario:WordPressBench/benchWordPressOverhead-appsec
|
| // check that the uid of the shared memory segment is the same as ours | ||
| struct ::stat shm_stat {}; | ||
| if (::fstat(fd, &shm_stat) == -1) { | ||
| throw std::runtime_error{ | ||
| "Call to fstat on memory segment failed: " + strerror_ts(errno)}; | ||
| } | ||
| if (shm_stat.st_uid != ::getuid()) { | ||
| throw std::runtime_error{"Shared memory segment does not have the " | ||
| "expected owner. Expect our uid " + | ||
| std::to_string(::getuid()) + " but found " + | ||
| std::to_string(shm_stat.st_uid)}; | ||
| } |
There was a problem hiding this comment.
Why are we checking that in the first place? Maybe do it within MAP_FAILED condition to give a better message, but no need to check that ahead of time.
There was a problem hiding this comment.
if you're referring to the owner, to check whether the file was not actually put there by another, possibly unprivileged, user.
There was a problem hiding this comment.
I see, that makes sense. Then the tracer should have the same check actually. However you should use geteuid, not getuid then. As the sidecar is bound to the effective user id too.
2c3f99b to
b424aab
Compare
f1b0cb1 to
bee3eef
Compare
Anilm3
left a comment
There was a problem hiding this comment.
After an extensive review and testing, the only thing that remains a mystery is the missing ASM_TRUSTED_IPS capability.
Please fix that before merging.
93fa0f0 to
4b1cb4d
Compare
4b1cb4d to
1856dd0
Compare
Description
Reviewer checklist