You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
install: create leading directories in write-only directories - #14779
install -D could not create leading directories inside a directory that is writable and searchable but not readable, where GNU 9.12 can:
$ mkdir wx && chmod 300 wx && echo hi > f
$ install -D f wx/sub/f
install: cannot create directory 'wx/sub': Permission denied
create_dir_all_safe anchored its walk with an O_RDONLY | O_DIRECTORY open of the deepest existing ancestor, which needs read permission; mkdirat only needs write and execute. It now uses DirFd::open_anchor, which falls back to a search-only descriptor (O_PATH on Linux/Android, O_SEARCH on Apple targets, FreeBSD, NetBSD, illumos and Solaris) on EACCES. The NoFollow opens in the descent are unchanged. Platforms with neither flag, including OpenBSD, still fail with EACCES here.
Based on #15120; until it merges, the diff here shows its commit too.
About the red Tests (unix) job: that runner is OpenBSD 7.9, which has neither O_PATH nor O_SEARCH, so there's no way to anchor *at calls on a directory we can't read and this approach can't work there. safe_traversal now exports SEARCH_ONLY_SUPPORTED and the new test skips when it's false.
To be explicit about the gap: install -D into a write-only directory still fails on OpenBSD, exactly as it did before this PR. The fix applies on Linux, macOS, FreeBSD, NetBSD and the Solaris family. I could add a path-based fallback for the rest, but that trades the fd-anchored traversal for plain path resolution and I'd rather not do that silently — tell me if you want it.
No successful run was found on main (8460811) during the generation of this report, so 8edf725 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
The Linux explanation here is inaccurate: O_PATH does not ignore O_NOFOLLOW; with O_PATH|O_NOFOLLOW it refers to the symlink itself (and combining O_DIRECTORY can reject it), rather than resolving it. The fallback intentionally omits O_NOFOLLOW to preserve Follow semantics, so document that choice directly instead of attributing it to an ignored flag.
This issue also appears on line 230 of the same file.
The reason will be displayed to describe this comment to others. Learn more.
Done in 991db22, which is now its own PR (#15120): uucore's build script defines has_o_path and has_o_search, and the constants and unit tests are gated on those. The install integration test still spells out the target list once, because uucore's build-script cfgs don't reach the root test crate; comments on both sides point at each other.
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 991db22: the search-only retry returns its own error, so an ENOENT or ELOOP from the retry is reported as such instead of the first open's EACCES. A unit test calls the retry directly for ENOENT, ELOOP and ENOTDIR.
Open a directory readable, and on EACCES retry with O_PATH or O_SEARCH,
which anchor *at calls without read access. The targets with either flag
are named by the has_o_path and has_o_search cfg aliases. If the retry
fails, its own error is returned.
install -D opened the deepest existing ancestor read-only, so it failed
with EACCES when that directory had write and execute but not read
permission, while GNU install succeeds. Open it with DirFd::open_anchor.
The reason will be displayed to describe this comment to others. Learn more.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
install -Dcould not create leading directories inside a directory that is writable and searchable but not readable, where GNU 9.12 can:create_dir_all_safeanchored its walk with anO_RDONLY | O_DIRECTORYopen of the deepest existing ancestor, which needs read permission;mkdiratonly needs write and execute. It now usesDirFd::open_anchor, which falls back to a search-only descriptor (O_PATHon Linux/Android,O_SEARCHon Apple targets, FreeBSD, NetBSD, illumos and Solaris) on EACCES. TheNoFollowopens in the descent are unchanged. Platforms with neither flag, including OpenBSD, still fail with EACCES here.Based on #15120; until it merges, the diff here shows its commit too.
Fixes #14778