oscerd opened a new issue, #729:
URL: https://github.com/apache/camel-karaf/issues/729
## Description
Several `camel-core-osgi` lookups build an OSGi/LDAP service filter by string
concatenation, without escaping the name that is interpolated into it:
- `OsgiBeanRepository.lookupByNameAndType` -- `"(name=" + name + ")"` (line
60)
- `OsgiBeanRepository.lookupByName` -- `"(" + Constants.SERVICE_PID + "=" +
name + ")"` (lines 83-85)
- `OsgiComponentResolver` -- `"(component=" + name + ")"` (line 53)
- `OsgiLanguageResolver` -- `"(language=" + name + ")"` (line 62) and
`"(resolver=" + name + ")"` (line 82)
- `OsgiDataFormatResolver` -- `"(dataformat=" + name + ")"` (line 62)
LDAP filter metacharacters in a name are therefore interpreted as filter
syntax rather than matched literally. A name of `*` becomes a presence filter
that matches every registered service, and the code takes `refs[0]` -- so the
lookup returns an arbitrary service instead of failing to resolve. A name
containing `)(` produces an `InvalidSyntaxException` rather than a clean
"not found".
`OsgiBeanRepository.lookupByName` additionally treats the name as an
interface
FQCN via `bundleContext.getServiceReference(name)` (line 80). That is the
documented purpose of the class, but combined with the unescaped
`service.pid`
filter it means the set of names that resolve is wider than an exact-match
lookup would give.
## Expected Behavior
A name that is not a legitimate identifier does not resolve to an arbitrary
service. Either the name is escaped per RFC 4515 before being embedded, or it
is validated against the legal character set for the lookup and rejected
otherwise. Where a filter is used to find a named service, the returned
reference's property is checked for equality against the requested name --
the same defensive pattern `OsgiNamingHelper.findFreeCamelContextName`
already applies.
## Actual Behavior
Metacharacters are passed straight through into the filter. `*` selects an
arbitrary service; `)(` faults the exchange with a syntax error.
## Additional Context
- The built-in `Bundle*Resolver` implementations second-stage the raw name
through an exact per-bundle map lookup, so for the resolver classes a
wildcard selects a resolver but generally instantiates nothing. The
remaining effects there are nondeterministic dispatch and the syntax fault.
`OsgiBeanRepository` has no such second stage.
- Suggested fix is deliberately conservative: escape/validate only, and keep
the existing FQCN and `service.pid` interpretations intact, since removing
either would be a behaviour change for existing deployments.
---
_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]
