checkValidNsPath treats permission-denied and I/O errors as "namespace does not exist"

Open Beginner friendly
#890 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
go

Research direction

Start in pkg/unikontainers/utils.go at checkValidNsPath and inspect how its Lstat error is returned to callers. Verify that a missing path still produces ErrNotExistingNS while permission, I/O, and symlink-loop errors retain their original causes with context; existing relevant tests should be updated or added if present.

Written by the indexing model from the issue text.

Description

Core enhancement

In pkg/unikontainers/utils.go, checkValidNsPath treats any os.Lstat failure as ErrNotExistingNS:

func checkValidNsPath(path string) error {
    if _, err := os.Lstat(path); err != nil {
        return ErrNotExistingNS
    }
    ...

Permission denied, I/O errors, and symlink loops all get collapsed into the same "namespace doesn't exist" case. This is misleading during debugging: a permissions or filesystem issue looks identical to a namespace simply not being configured, which sends anyone troubleshooting a permissions problem down the wrong path.

Suggested fix:

if _, err := os.Lstat(path); err != nil {
    if errors.Is(err, os.ErrNotExist) {
        return ErrNotExistingNS
    }
    return fmt.Errorf("failed to query namespace path %s: %w", path, err)
}

This distinguishes a namespace that genuinely hasn't been created yet from a path resolution or permission failure, while preserving the original error for anyone further up the call stack.

Related: #884 (part of a broader pattern of specific errors getting collapsed into generic sentinels, discussed there and split per maintainers suggestion).

Dominant language
Go
Stars
298
Forks
202
Avg merge
2d 18h
Merged PRs (30d)
28

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from urunc-dev/urunc

All issues in urunc-dev/urunc

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.