oscerd commented on issue #2980:
URL:
https://github.com/apache/camel-kamelets/issues/2980#issuecomment-5434534356
## Correction: `camel-exec` is not at fault
I filed this saying `camel-exec` "does not read" its documented
`CamelExecCommand*` headers. **That framing is wrong** and I want it corrected
in the record before anyone acts on it.
`camel-exec` gates every one of those headers behind an opt-in endpoint
option. From `DefaultExecBinding.readInput`:
```java
Object args = endpoint.isAllowControlHeaders() ?
exchange.getIn().removeHeader(EXEC_COMMAND_ARGS) : null;
String cmd = getAndRemoveHeader(endpoint, exchange.getIn(),
EXEC_COMMAND_EXECUTABLE, endpoint.getExecutable(), String.class);
...
```
and `ExecEndpoint`:
```java
@UriParam(label = "advanced")
private boolean allowControlHeaders;
```
> Whether to allow to use Camel headers or not (**default false**). Enabling
this allows to specify dynamic command line arguments via message header.
However this can be seen as a potential security vulnerability if the header is
coming from a malicious user, so use this with care.
So the observed behaviour — headers present and unconsumed after the call,
URI parameters winning — is the **documented, intentional, secure default**.
There is no upstream bug and nothing to fix in `apache/camel`.
## The real defect, and it is ours
`docs/modules/ROOT/partials/exec-sink-description.adoc` promises a feature
the Kamelet cannot deliver:
```
=== Optional Headers
The Kamelet supports the following optional headers:
- `args` / `ce-args`: Command line arguments to pass to the executable
```
`exec-sink` maps `args` / `ce-args` onto `CamelExecCommandArgs` but never
sets `allowControlHeaders=true`, so `camel-exec` discards the header. The
documented interface is dead on arrival. Retitled accordingly.
## This also vindicates dropping the exec-sink half of #2978
#2978 originally stripped `CamelExecCommandExecutable` / `WorkingDir` /
`OutFile` in `exec-sink`. It was dropped for being a no-op — which was the
right call for a better reason than the one given at the time: `camel-exec`
already refuses those headers by default, so the strip guarded a door that is
bolted shut.
That changes the shape of a fix here. Two coherent directions:
**(a) Retract the claim.** Drop the `args` / `ce-args` mapping from the
template and the Optional Headers section from the doc partial. Keeps the
secure default; removes a documented-but-non-functional feature.
**(b) Deliver the feature, contained.** Set `allowControlHeaders=true` *and*
strip the whole `CamelExec*` family ahead of the mapping, so only
`CamelExecCommandArgs` — derived from the advertised `args` / `ce-args` —
survives, and the executable stays pinned to `exec:{{executable}}`. This makes
the #2978 strip load-bearing instead of decorative.
(b) relaxes a security-relevant component default in a shared catalog, so
per the contributor guidelines it would need an upgrade-guide entry and PMC
sign-off. Flagging for maintainer direction rather than picking unilaterally.
---
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
