[
https://issues.apache.org/jira/browse/CAMEL-24415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106757#comment-18106757
]
Andrea Cosentino commented on CAMEL-24415:
------------------------------------------
Settling test run on POSIX (Linux, JDK 21), results below. This resolves the
open backport question on this issue.
*Confirmed*: a file whose name legitimately contains backslashes is accepted by
the filesystem, and normalizePathToProtocol rewrites it into a multi-component
relative path. With a file literally named {{x\\..\\..\\escaped.txt}} dropped
in the consumed directory, the consumer produced:
{noformat}
CamelFileName = x/../../escaped.txt
CamelFileNameOnly = x\\..\\..\\escaped.txt <- the real name, unmangled
CamelFileRelativePath = x/../../escaped.txt
CamelFilePath = <inbox>/x/../../escaped.txt
CamelFileParent = <inbox>/x/../..
{noformat}
So CamelFileName, CamelFileRelativePath and CamelFilePath all carry a traversal
path derived from the file name, while CamelFileNameOnly keeps the true name.
That is the defect, and it is worth fixing: these are the headers routes read
and pass on.
*Not confirmed - the sink is already contained.* Driving the file producer
directly with the corrupted CamelFileName value is refused:
{noformat}
java.lang.IllegalArgumentException: Cannot write file with name:
<testdir>/escaped.txt
as the filename is jailed to the starting directory: <testdir>/outbox/
{noformat}
That is the jailStartingDirectory guard, which defaults to true. A
from(file:inbox).to(file:outbox) route therefore fails the exchange rather than
writing outside the directory, and in the consumer-only probe no out-of-root
move or delete occurred either.
*Conclusion for this issue*
* The header mangling is real and should be fixed - a legal single-component
POSIX file name should not become a multi-component path.
FileUtil.normalizePath() already models the right behaviour (it only translates
the separator that is not legal on the current platform).
* Priority is lower than first assessed: with the shipped default the main
file-producer sink refuses the resulting path.
* Residual exposure worth covering in the fix or a follow-up: endpoints
configured with jailStartingDirectory=false, and any sink that consumes
CamelFileName / CamelFilePath without that guard.
*Backport decision*: main only for now. The behaviour change touches file
naming, and the default jail already contains the primary sink, so there is no
case for pushing it onto the maintenance branches.
> camel-file - normalizePathToProtocol turns a backslash in a legal POSIX file
> name into a path separator
> -------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24415
> URL: https://issues.apache.org/jira/browse/CAMEL-24415
> Project: Camel
> Issue Type: Bug
> Components: camel-file
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> GenericFile.normalizePathToProtocol() rewrites both separators
> unconditionally:
> path = path.replace('/', getFileSeparator());
> path = path.replace('\\', getFileSeparator());
> and is applied in setFileName() and setRelativeFilePath(), and when building
> the CamelFilePath header.
> On POSIX a backslash is a legal character in a file name, so a
> single-component file name that contains backslashes is rewritten into a
> multi-component relative path. Downstream strategies that resolve the file
> name against the endpoint directory (delete, move, done-file/marker handling)
> then operate on a different path than the one that was actually read.
> Proposal: only translate the separator that is not legal on the current
> platform (FileUtil.normalizePath() already does exactly this - on POSIX it
> maps '\\' to '/' only when running on Windows), or keep the consumed file
> name as an opaque single component. Needs a regression test on POSIX using a
> file whose name legitimately contains backslashes.
> Before changing behaviour, confirm on a POSIX box which of the
> delete/move/marker strategies actually resolve out of the starting directory,
> so the fix targets the right layer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
