[
https://issues.apache.org/jira/browse/CAMEL-24415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107071#comment-18107071
]
Andrea Cosentino commented on CAMEL-24415:
------------------------------------------
*Correction to the issue description.* It says FileUtil.normalizePath()
"already models the right behaviour ... on POSIX it maps \\ to / only when
running on Windows". That is wrong, and self-contradictory as written.
FileUtil.normalizePath() does the same thing GenericFile does:
{code:java}
public static String normalizePath(String path) {
if (path == null) return null;
if (isWindows()) {
return path.replace('/', '\\');
} else {
return path.replace('\\', '/'); // POSIX: backslash -> slash, i.e.
the same rewrite
}
}
{code}
So it is not a model to copy for this.
*The real distinction is path versus name, not platform.* Rewriting separators
is reasonable for a *path*: a relative path written with Windows separators
should still resolve on POSIX, and relativeFilePath legitimately contains
directory components when recursive=true. It is not reasonable for a *file
name*, which is a single path component by definition and where a backslash is
an ordinary character on POSIX.
GenericFile.normalizePathToProtocol() is currently applied to both, via
setFileName() and setRelativeFilePath().
Revised proposal: stop applying separator rewriting to the file name
specifically, and keep it for the path. That preserves the cross-platform
behaviour the method exists for while ending the case where a legal
single-component POSIX name becomes a multi-component relative path. A
regression test should assert that a consumed file named with embedded
backslashes reports CamelFileName equal to CamelFileNameOnly.
Reminder of the practical bound established earlier on this issue: the file
producer already refuses the resulting path (jailStartingDirectory defaults to
true), so this is a correctness fix on the headers rather than an exploitable
traversal at shipped defaults.
> 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)
