Skip to content

Tighten path containment in Live Migration file route#367

Open
nvharikrishna wants to merge 3 commits into
apache:trunkfrom
nvharikrishna:lm-file-resolver-double-encoded-path-traversal
Open

Tighten path containment in Live Migration file route#367
nvharikrishna wants to merge 3 commits into
apache:trunkfrom
nvharikrishna:lm-file-resolver-double-encoded-path-traversal

Conversation

@nvharikrishna

Copy link
Copy Markdown
Contributor

Making this change as part of CEP-40.

CASSSIDECAR-479 Tightens the path check on the Live Migration file route so that symlinks inside a data directory cannot point to files outside the configured directory.

Earlier, the route only checked the URL text for .. patterns. That check does not catch symlinks, so a symlink within the data dir could still resolve to a file elsewhere on disk. The route now also resolves the path with toRealPath() and confirms the resolved path stays inside the configured base directory.

Comment on lines +66 to +72
/**
* Caches the canonical (symlinks resolved) form of each base directory keyed by its lexical
* path. Base directories come from {@link InstanceMetadata}, which is fixed at startup, so the
* canonical form is stable for the process lifetime. The set of distinct base directories is
* bounded by configuration (~5–10 per instance), so no eviction is required.
*/
private static final ConcurrentMap<Path, Path> BASE_DIR_CANONICAL = new ConcurrentHashMap<>();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that the LiveMigrationInstanceMetadataUtil is a static helper already. But the static map BASE_DIR_CANONICAL catches my attention. I have 2 suggestions.

  1. It is common in this project to inject util via guice. Can we do the same, instead of an unmanaged global object out side of guice?
  2. To harden the assumption on the size, can we set a size limit and emit warning if exceeding certain size (say 10) when inserting into the map.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class is a utility class and all its methods are static, so Guice cannot be used. Compared to all other work done during downloading, I think the save by this cache is very minimal. For simplicity, I can remove the cache entirely.

Comment on lines -146 to +156
rc.response().setStatusCode(HttpResponseStatus.NOT_FOUND.code()).end();
rc.fail(wrapHttpException(HttpResponseStatus.BAD_REQUEST, e.getMessage(), e));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it expected? 404 -> 400

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing it out. There is some ambiguity w.r.t usage of IllegalArgumentException. Changed it to BAD_REQUEST as resolveLexically throws it for malformed URL. This usage is overlapping with file/dir that don’t exist. Introduced new exception to bring clear separation between malformed URLs and well constructed URLs, but file/directory doesn't exist so that existing behavior is preserved.

{
throw new NoSuchFileException(resolvedPath.toString());
}
Path canonical = resolvedPath.toRealPath();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like toRealPath already throws NoSuchFileException when the file does not exist. The above check is redundant.

@throws IOException – if the file does not exist or an I/O error occurs

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@throws IOException – if the file does not exist or an I/O error occurs

Documentation says IOException, and implementation may throw just IOException and not NoSuchFileException. So, checking for file existence and throwing NoSuchFileException explicitly.

…based path traversal by validating that the canonical resolved path stays within the configured directory. Return clearer HTTP status codes - 400 for malformed URLs, 403 for symlink escapes, 404 for missing or excluded files - with consistent JSON error responses. Preserve operator-configured directory paths in exclusion matching and logs so behavior stays predictable when data dirs sit behind symlinks.
@nvharikrishna
nvharikrishna force-pushed the lm-file-resolver-double-encoded-path-traversal branch from 9147366 to ce2719a Compare July 15, 2026 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants