Reject ambiguous resource paths with inner ".." to prevent silent misresolution

[0xMH]

I dug into #5979 where a YAML indentation error silently causes kustomize to load resources from the wrong directory.

When a kustomization.yaml has a subtle indentation mistake:

resources:
- ../../base
 - ../../shared/prod
- m3.yaml

YAML parsing collapses the first two entries into a single string: "../../base - ../../shared/prod".

The combined string then hits filepath.Clean, which processes the segments:

1. .. + .. -> normal, goes up two directories
2. base - .. -> treated as a single directory name (with spaces and dash)
3. .. -> Clean sees this and cancels the previous component (base - ..), removing it
4. .. -> goes up one more
5. shared/prod -> descends into final path

So Clean collapses it to ../../shared/prod. The base - .. segment gets absorbed by the .. that follows it, as if it never existed.

The root cause is that YAML merged two list entries into one string ("../../base - ../../shared/prod"), creating a path component base - .. that looks like a directory name but contains .. from the second entry. filepath.Clean then treats the subsequent .. as "go up", which eats base - .. and erases any trace of ../../base.

Since /shared/prod is a real directory, ConfirmDir passes and kustomize silently loads the wrong resources. No error is raised. This is dangerous in CI/CD environments where missing manifests can cause resources to be deleted.

Fix

I added a hasInnerDotDot check in FileLoader.New() that rejects paths containing .. after a non-.. component. These are always either a YAML artifact or a non-canonical path with a simpler equivalent (foo/../bar is just bar). No valid use case that I know of is affected.

There was a prior attempt in #5980, but it checked existence after normalization, so if the wrong directory exists the check passes.

/kind bug
/fix #5979

[k8s-ci-robot]

Hi @0xMH. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[chansuke]

/ok-to-test

[k8s-ci-robot]

This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[0xMH]

/label tide/merge-method-squash

[koba1t]

@0xMH
Could you fix lint error?

[0xMH]

@koba1t Done!

[0xMH]

Hi @koba1t, I think the lint errors reported in CI are all pre-existing issues in fileloader_test.go not introduced by this PR. Correct me if I'm wrong but I think that's because the PR touches this file, golangci-lint re-evaluates it against the new-from-rev baseline (c94b5d8f2) and flags old code: unchecked error returns (errcheck), unused assignments (ineffassign, staticcheck), a global variable (gochecknoglobals), and a missing http.StatusOK constant (usestdlibvars).

I'm happy to fix them in a separate commit on this PR, but wanted to flag that none of these are caused by my changes. What should we do in this situation? Would you prefer I clean them up here, or should they be addressed in a separate PR?

[koba1t]

@0xMH
It's okay to add a fix commit for the linter to this PR.

[0xMH]

@0xMH It's okay to add a fix commit for the linter to this PR.

@koba1t Perfect, Did that now.

[koba1t]

Thank you for your contribution!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 0xMH, chansuke, koba1t

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [koba1t]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment