This was likely meant as a fallback for non-`std::exception`
exception pointers, but it would never have been reached, because
`(std|boost)::rethrow_exception()` would have thrown those out of
the function scope.
This fixes the fallback by making it a catch handler and also using
the more direct way of getting this fallback diagnostic info inside
a catch handler.
The recursion depth limit added to JsonDecode() in 2.16.2 gave the C++
function a second parameter with a default value. Function pointers do not
carry default arguments, so the DSL function binding deduced an arity of 2
via boost::function_types::function_arity and required two arguments. As a
result `Json.decode("...")` failed with "Too few arguments for function",
an undocumented breaking change in a patch release.
Wrap JsonDecode() in a single-argument shim (mirroring the existing
JsonEncodeShim) so the registered function keeps its one-parameter contract
while still applying the default depth limit internally.
refs #10913
More relaxed memory_order = less safety guarantees = faster execution.
This is safe because std::shared_ptr does the same. See also:
https://en.cppreference.com/w/cpp/atomic/memory_order
"Typical use for relaxed memory ordering is incrementing counters, such as the reference counters of std::shared_ptr, since this only requires atomicity, but not ordering or synchronization (note that decrementing the std::shared_ptr counters requires acquire-release synchronization with the destructor)."
In the `boost::asio::spawn()` call for newer Boost versions with
`std::allocator_arg`, switch from `fixedsize_stack` to
`protected_fixedsize_stack` in order to allocate the stacks with guard pages.
This is done as an additional safeguard in case there was still some way to
overflow, this at least reliably crashes the process instead of going into
undefined behavior, which could even result in code execution.
Unfortunately, the old-style `spawn()` function with
`boost::coroutines::attributes` does not - at least to my knowledge - provide a
way to request a stack allocated with guard pages, hence this is only enabled
for Boost 1.87 and later with this commit.
Add validation checks to code paths reachable from the HTTP API (except full
config file deployments via /v1/config) that prevent creating deeply nested
data structures that could later cause a stack overflow.
With the limit from the previous commit, if a JSON-RPC now message fails to
parse due to being nested to deep, it would have torn down the whole
connection. It is still possible to trigger that scenario from DSL config (for
example by returning nested structures from a lambda that is used in a check
with command_endpoint). In order to fail more gracefully, only discard the
single message and don't kill the whole connection.
If parsing JSON is rejected due to the depth limit introduced in the last
commit, also include the path (like root["object"]["children"]...) that exceeds
the allowed nesting depth.
Data structures parsed from JSON may be accessed recursively, so deeply nested
structures may wreak havoc by overflowing the stack. Thus, enforce a general
nesting depth limit of 24 by default (which should be more than enough for
reasonable use), with the ability to pass a different limit to JsonDecode() if
needed.
Since perfdata is set once when a check result is created and
never changed again, locking this is unnecessary. This avoids
components unnecessarily waiting on each other when processing
perfdata.
This fixes the locking cascade observed sometimes when the perfdata
writer work queue blocks, where it extends to a lock on the entire
check result eventually, affecting even more components.
Icinga (DB) Web has a special permission to show the check command line.
Well-written plugins receive passwords via env vars which don't appear even there.
Now ifw-api also hides the password using curl -u USER, not USER:PASS.
The new command is still working, it just prompts for the password.
int is just not the right type to use for an index variable, so change it to
size_t, even if it's unlikely to be called on sufficently large inputs that it
would actually make a difference.
Forgot to replace one of the two uses of SHA_DIGEST_LENGTH with length in
6cd3a483a0. All users use it for SHA1 so far, so
there was no wrong usage yet.
This was omitted by accident from the original PR, despite
being done in the original perfdata writer connection code.
Without setting this parameter, host name verification will be
disabled, which poses a security risk.
The log message on TLS handshake errors always stated that a client handshake
failed, even if if the connection was acting as the server. The commit changes
it so that the actual role is taken into account.
`strand.running_in_this_thread()` relies on thread-local storage
internally, and may return false positives if the coroutine is resumed
in a different thread than it was suspended in. In debug builds, this is
not problem, since there's no TLS optimization done by the compiler, but
in release builds, the compiler might cache the address of the
thread-local variable read before the coroutine suspension, and thus
potentially reuse the same address in a different thread after
resumption, which would cause `running_in_this_thread()` to return false
or even crash (but we didn't see any crashes related to this). So,
perform the assertion only in debug builds to prevent potential wrong
usages of the `Timeout` class. For more details, see [^1][^2][^3].
[^1]: https://github.com/chriskohlhoff/asio/issues/1366
[^2]: https://bugs.llvm.org/show_bug.cgi?id=19177
[^3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
Escape all user-supplied template imports when creating an Icinga 2 DSL
configuration object. Without the escape, a `"` within the template name
would allow escaping the created object and create other Icinga 2 DSL
objects, exceeding potential user privileges.
The same bug was present in ConfigWriter::EmitComment, but as this
method is dead code, it could just be removed.
In Url::ParseUserinfo, after extracting the password, ValidateToken is
incorrectly called upon m_Username instead of m_Password. This commit
fixes this and actually verifies the password.
The bug was introduced with the surrounding code in 6571ffc2c8.
Luckily, this does not seem to have any security impact. However, as
being a bug, this commit now fixes the behavior.
Now, the individual `ProcessQueueItem` functions decide whether to
acquire an `olock` or not instead of probing this from within the
worker loop. This is way easier than having to deal with the potential
out of order processing of items in the queue in both ways, i.e., we
don't want to send delete events for objects while their created events
haven't been processed yet and vice versa.
This commit restructures the queue items so that each one now has a method
`GetQueueLookupKey()` that is used to derive which elements of the queue are
considered to be equal. For this, there is a key extractor for the
`multi_index_container` that takes the `variant` from the queue item, calls
that method on it, and puts the result in a second variant type. The types in
that variant type are automatically deduced from the return types of the
individual methods.
