oscerd opened a new pull request, #3066:
URL: https://github.com/apache/camel-kamelets/pull/3066
Fixes #2980.
`exec-sink` advertises an inbound `args` / `ce-args` header that has never
done anything. This removes the claim rather than relaxing a security-relevant
component default.
## The defect
The doc partial promises:
```
=== Optional Headers
The Kamelet supports the following optional headers:
- `args` / `ce-args`: Command line arguments to pass to the executable
```
and the template maps it onto the component header:
```yaml
- choice:
when:
- simple: "${header[args]}"
steps:
- setHeader:
name: CamelExecCommandArgs
simple: "${header[args]}"
```
But `camel-exec` gates that header behind an endpoint option. From
`DefaultExecBinding.readInput`:
```java
Object args = endpoint.isAllowControlHeaders()
? exchange.getIn().removeHeader(EXEC_COMMAND_ARGS) : null;
```
`allowControlHeaders` defaults to `false` — deliberately, since its own
Javadoc calls dynamic arguments from a header *"a potential security
vulnerability if the header is coming from a malicious user"* — and `exec-sink`
never sets it. So the header is mapped and then discarded.
This is **not** an upstream bug. I originally filed it as one
([CAMEL-24464](https://issues.apache.org/jira/browse/CAMEL-24464)) and
corrected that on the issue: the behaviour is camel-exec's documented,
intentional, secure default.
## Why (a) and not (b)
The issue laid out two coherent directions. This is **(a) retract the
claim**.
**(b) deliver the feature, contained** — set `allowControlHeaders=true`
*and* strip the rest of the `CamelExec*` family ahead of the mapping — remains
available if the feature is ever actually wanted. It 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. Direction
chosen by @oscerd.
## Evidence the removal is a no-op
`camel run` on Camel 4.22.0, calling the Kamelet with `executable=echo` and
an `args` header, against the template before and after:
| | stdout | `CamelExecCommandArgs` after the call |
|---|---|---|
| **old** | `[\n]` — echo ran with no args | `HEADER-ARGS` — mapped, then
ignored |
| **new** | `[\n]` — identical | *(unset)* |
Identical output. The mapping's one observable effect was leaving a
Camel-internal dispatch header set on the outgoing message, which now stops too
— a small bonus given the security model's interest in stray `Camel*` headers.
Control on the same runtime, so the empty stdout is the header being ignored
rather than a silent exec failure:
```
A) CamelExecCommandArgs header -> stdout=[]
B) exec:echo?args=URI-ARGS -> stdout=[URI-ARGS]
```
## Also corrected: security-model.adoc
The security model used this exact mapping as its example of *"a Kamelet
doing, by design, the dangerous thing it is named for"*:
```diff
- `exec-sink` ("Execute system commands") deliberately maps an inbound
`args` /
- `ce-args` header into `CamelExecCommandArgs` and runs
`exec:{\{executable}}`;
+ `exec-sink` ("Execute system commands") runs `exec:{\{executable}}` with
the
+ executable bound by the operator;
```
`exec-sink` still belongs in that bullet — it runs `exec:{\{executable}}`
with an operator-bound executable — it just no longer reads anything from the
message.
This also closes the loop on #2978, where the `exec-sink` half (stripping
`CamelExecCommandExecutable` / `WorkingDir` / `OutFile`) was dropped for being
a no-op. That was right for a better reason than the one recorded at the time:
`camel-exec` already refuses those headers by default, so the strip guarded a
door that is bolted shut.
## Verification
- `mvn clean install -DskipTests` from the repository root: clean, and it
regenerated only the `library/camel-kamelets` resource copy of
`exec-sink.kamelet.yaml` (included here). No other Kamelet touched, no nav or
SBOM drift.
- Four files changed, all of them this one Kamelet and its docs.
---
_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]
