Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update module github.com/cyphar/filepath-securejoin to v0.3.6 #6066

Merged
merged 1 commit into from
Dec 17, 2024

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Dec 17, 2024

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
github.com/cyphar/filepath-securejoin v0.2.4 -> v0.3.6 age adoption passing confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


Release Notes

cyphar/filepath-securejoin (github.com/cyphar/filepath-securejoin)

v0.3.6

Compare Source

This release lowers the minimum Go version to Go 1.18 as well as some
library dependencies, in order to make it easier for folks that need to
backport patches using the new filepath-securejoin API onto branches
that are stuck using old Go compilers. For users using Go >= 1.21, this
release contains no functional changes.

  • The minimum Go version requirement for filepath-securejoin is now Go 1.18
    (we use generics internally).

    For reference, filepath-securejoin@v0.3.0 somewhat-arbitrarily bumped the
    Go version requirement to 1.21.

    While we did make some use of Go 1.21 stdlib features (and in principle Go
    versions <= 1.21 are no longer even supported by upstream anymore), some
    downstreams have complained that the version bump has meant that they have to
    do workarounds when backporting fixes that use the new filepath-securejoin
    API onto old branches. This is not an ideal situation, but since using this
    library is probably better for most downstreams than a hand-rolled
    workaround, we now have compatibility shims that allow us to build on older
    Go versions.

  • Lower minimum version requirement for golang.org/x/sys to v0.18.0 (we
    need the wrappers for fsconfig(2)), which should also make backporting
    patches to older branches easier.

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v0.3.5

Compare Source

This release primarily includes a fix for an issue involving two
programs racing to MkdirAll the same directory, which caused a
regression with BuildKit.

  • MkdirAll will now no longer return an EEXIST error if two racing
    processes are creating the same directory. We will still verify that the path
    is a directory, but this will avoid spurious errors when multiple threads or
    programs are trying to MkdirAll the same path. opencontainers/runc#4543

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v0.3.4

Compare Source

This release primarily includes a fix that blocked using
filepath-securejoin in Kubernetes.

  • Previously, some testing mocks we had resulted in us doing import "testing"
    in non-_test.go code, which made some downstreams like Kubernetes unhappy.
    This has been fixed. (#​32)

Thanks to all of the contributors who made this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v0.3.3

Compare Source

This release primarily includes fixes for spurious errors we hit when
checking that directories created by MkdirAll "look right". Upon further
consideration, these checks were fundamentally buggy and didn't offer
any practical protection anyway.

  • The mode and owner verification logic in MkdirAll has been removed. This
    was originally intended to protect against some theoretical attacks but upon
    further consideration these protections don't actually buy us anything and
    they were causing spurious errors with more complicated filesystem setups.
  • The "is the created directory empty" logic in MkdirAll has also been
    removed. This was not causing us issues yet, but some pseudofilesystems (such
    as cgroup) create non-empty directories and so this logic would've been
    wrong for such cases.

Thanks to all of the contributors who made this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v0.3.2

Compare Source

This release includes a few fixes for MkdirAll when dealing with S_ISUID
and S_ISGID, to solve a regression runc hit when switching to MkdirAll.

  • Passing the S_ISUID or S_ISGID modes to MkdirAllInRoot will now return
    an explicit error saying that those bits are ignored by mkdirat(2). In
    the past a different error was returned, but since the silent ignoring
    behaviour is codified in the man pages a more explicit error seems
    apt. While silently ignoring these bits would be the most compatible
    option, it could lead to users thinking their code sets these bits
    when it doesn't. Programs that need to deal with compatibility can
    mask the bits themselves. (#​23, #​25)

  • If a directory has S_ISGID set, then all child directories will have
    S_ISGID set when created and a different gid will be used for any
    inode created under the directory. Previously, the "expected owner and
    mode" validation in securejoin.MkdirAll did not correctly handle this.
    We now correctly handle this case. (#​24, #​25)

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v0.3.1

Compare Source

  • By allowing Open(at)InRoot to opt-out of the extra work done by MkdirAll
    to do the necessary "partial lookups", Open(at)InRoot now does less work
    for both implementations (resulting in a many-fold decrease in the number of
    operations for openat2, and a modest improvement for non-openat2) and is
    far more guaranteed to match the correct openat2(RESOLVE_IN_ROOT)
    behaviour.

  • We now use readlinkat(fd, "") where possible. For Open(at)InRoot this
    effectively just means that we no longer risk getting spurious errors during
    rename races. However, for our hardened procfs handler, this in theory should
    prevent mount attacks from tricking us when doing magic-link readlinks (even
    when using the unsafe host /proc handle). Unfortunately Reopen is still
    potentially vulnerable to those kinds of somewhat-esoteric attacks.

    Technically this will only work on post-2.6.39 kernels
    but it seems incredibly unlikely anyone is using filepath-securejoin on a
    pre-2011 kernel.

  • Several improvements were made to the errors returned by Open(at)InRoot and
    MkdirAll when dealing with invalid paths under the emulated (ie.
    non-openat2) implementation. Previously, some paths would return the wrong
    error (ENOENT when the last component was a non-directory), and other paths
    would be returned as though they were acceptable (trailing-slash components
    after a non-directory would be ignored by Open(at)InRoot).

    These changes were done to match openat2's behaviour and purely is a
    consistency fix (most users are going to be using openat2 anyway).

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v0.3.0

Compare Source

This release contains no changes to SecureJoin.

However, it does introduce a new *os.File-based API which is much safer
to use for most usecases. These are adapted from libpathrs and are
the bare minimum to be able to operate more safely on an untrusted
rootfs where an attacker has write access (something that SecureJoin
cannot protect against). The new APIs are:

  • OpenInRoot, which resolves a path inside a rootfs and returns an
    *os.File handle to the path. Note that the file handle returned by
    OpenInRoot is an O_PATH handle, which cannot be used for reading or
    writing (as well as some other operations -- see open(2) for more
    details
    ).

  • Reopen, which takes an O_PATH file handle and safely re-opens it to
    "upgrade" it to a regular handle.

  • MkdirAll, which is a safe implementation of os.MkdirAll that can be
    used to create directory trees inside a rootfs.

As these are new APIs, it is possible they may change in the future.
However, they should be safe to start migrating to as we have extensive
tests ensuring they behave correctly and are safe against various races
and other attacks.

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v0.2.5

Compare Source

This release makes some minor improvements to SecureJoin:

  • Some changes were made to how lexical components are handled during
    resolution. There is no change in behaviour, and both implementations
    are safe, however the newer implementation is much easier to reason
    about.

  • The error returned when a symlink loop has been detected will now
    reference the correct path. #​10

Signed-off-by: Aleksa Sarai cyphar@cyphar.com


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot requested a review from MrAlias as a code owner December 17, 2024 16:16
@renovate renovate bot added the dependencies Pull requests that update a dependency file label Dec 17, 2024
@renovate renovate bot requested a review from XSAM as a code owner December 17, 2024 16:16
@renovate renovate bot added the Skip Changelog PRs that do not require a CHANGELOG.md entry label Dec 17, 2024
@dmathieu dmathieu merged commit f8d12fc into main Dec 17, 2024
34 of 36 checks passed
@dmathieu dmathieu deleted the renovate/github.com-cyphar-filepath-securejoin-0.x branch December 17, 2024 16:21
@MrAlias MrAlias added this to the v1.34.0 milestone Jan 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file Skip Changelog PRs that do not require a CHANGELOG.md entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants