@trask @mateuszrzeszutek hello, what do you think about
SingleThreadedSpringWebfluxTest, the test contains dependencies on new
reactor netty classes in testLatestDeps case. I tried use reflection for
rewriting the test to java but it was not trivial and I not reach the
result
---------
Co-authored-by: Lauri Tulmin <ltulmin@splunk.com>
This pr gives classes defined in agent and extension class loaders all
permissions. Injected helper classes are also defined with all
permissions. Agent startup is altered so that we won't call methods that
require permission before we are able to get those permissions.
This pr does not attempt to address issues where agent code could allow
user code to circumvent security manager e.g.
https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/javaagent-bootstrap/src/main/java/io/opentelemetry/javaagent/bootstrap/InstrumentationHolder.java
gives access to `Instrumentation` that could be used to redefine classes
and remove security checks. Also this pr does not address failed
permission checks that could arise from user code calling agent code.
When user code, that does not have privileges, calls agent code, that
has the privileges, and agent code performs a sensitive operation then
permission check would fail because it is performed for all calling
classes, including the user classes. To fix this agent code should uses
`AccessController.doPrivileged` which basically means that, hey I have
done all the checks, run this call with my privileges and ignore the
privileges of my callers.
I think that the only way zipslip could happen is when name contains
`..` but codeql isn't able to cope with that. Removing the `..` check
gets rid of the code scanning alert.
Currently we run spotless and other checks for each of the parallel test
steps which seems wasteful. Here is an attempt to run only the tests in
given partition without any extra checks in the `test` step and run all
the checks in the `build` step.
Resolves#7437.
A few caveats about this. The TL;DR on #7437 is that a non-containerized
process was reporting a `container.id` attribute. The submitter narrowed
it down and I was able to confirm with the test case in this PR.
I hunted for other means for code to determine if it's containerized
with the idea to not even do the parsing if not containerized, but I
couldn't find anything useful. In fact, most approaches of detecting
containerization at all do involve parsing cgroups. Wacky.
So I attempted to verify that container IDs should always be 64
characters. I found:
* podman - docs
[here](https://docs.podman.io/en/latest/markdown/podman-container-inspect.1.html)
"Container ID (full 64-char hash)"
* docker - UID generator source
[here](634a848b8e/pkg/stringid/stringid.go (L36))
shows 32 bytes (and even guards against fully numeric!)
* lxc [man page
](https://linuxcontainers.org/lxc/manpages/man1/lxc-info.1.html)says
"container identifier format is an alphanumeric string". If this maps
into cgroups (no idea!), it would have already been broken in some cases
because we enforce hex.
I'm a little concerned about this approach because the [otel
spec](94c9c75c4f/specification/resource/semantic_conventions/container.md)
suggests that "The UUID might be abbreviated.", but it's
unclear/non-specific about the circumstances that might cause this.
Open to hearing about why the approach presented here is a bad idea. 🙃
Related discussion #7257Resolves#3413Resolves#5059Resolves#6258Resolves#7179
Adds a logging implementation that'll collect agent logs in memory until
slf4j is detected in the instrumented application; and when that happens
will dump all the logs into the application slf4j and log directly to
the application logger from that time on.
It's still in a POC state, unfortunately: while it works fine with an
app that uses & initializes slf4j directly, Spring Boot applications
actually reconfigure the logging implementation (e.g. logback) a while
after slf4j is loaded; which causes all the startup agent logs (debug
included) to be dumped with the default logback pattern.
Future work:
* ~~Make sure all logs produces by the agent are sent to loggers named
`io.opentelemetry...`
(https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/7446)~~
DONE
* Make this work on Spring Boot
* Documentation
* Smoke test?
the current implementation of Start and End around the invocation of a
Jax WS is asymmetric around the JAX-WS Handler Chain.
Current behavior:
(execution of incoming MessageHandlers) -> (TracingStartInInterceptor)
-> (WebService Invocation) -> (execution of outgoing MessageHandlers) ->
(TracingEndInInterceptor)
if I understood the code of this cxf instrumentation correctly, the
intent was to build the span close around the WebService Invocation
(without Handler Chains).
So the desired behavior would look like this:
(execution of incoming MessageHandlers) -> (TracingStartInInterceptor)
-> (WebService Invocation) -> (TracingEndInInterceptor) -> (execution of
outgoing MessageHandlers)
Unfortunately CXF is calling the Outgoing Chain inside the POST_INVOKE
Phase of Cxf (so the outgoing chain is technically a sub-chain in the
incoming chain... which is documented but quite surprising...).
So the solution in the fix at least guarantees the the outgoing chain is
invoked AFTER end of tracing. For any extra Interceptors in the
POST_INVOKE Phase there is still no guarantee of ordering, but I think
this is not a opentelemetry issue but a design-flaw of CXF...
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Lauri Tulmin <ltulmin@splunk.com>
this is a follow-up to #7043
I tried to add a test when that PR was opened:
*
d2c6399a6e
but it doesn't really verify anything, since the NPE is throw/caught and
same behavior occurs
This PR allows:
* Executing the OTel Logback appender tests as GraalVM native
executables
* Executing the native tests once a day on Github
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>