Bump github.com/cyphar/filepath-securejoin from 0.3.1 to 0.3.2

[dependabot]

Bumps github.com/cyphar/filepath-securejoin from 0.3.1 to 0.3.2.

Release notes

Sourced from github.com/cyphar/filepath-securejoin's releases.

v0.3.2

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

Changelog

Sourced from github.com/cyphar/filepath-securejoin's changelog.

[0.3.2] - 2024-09-13

Changed

• 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)

Fixed

• 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)

Commits

• e408943 VERSION: release v0.3.2
• 1c875f5 CHANGELOG: fix headers
• fdaafcc merge #25 into cyphar/filepath-securejoin:main
• 1acda83 mkdirall: correctly handle sgid directory parent
• 8484faf tests: mkdirall: refactor check and mkdirall helpers
• 350d697 mkdirall: explicitly return an error for suid/sgid bits
• 43b1026 tests: procfs: skip procfs tests if overmounting is blocked
• 82e5725 VERSION: back to development
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)