std::fs::set_symlink_permissions #582
Labels
ACP-accepted
API Change Proposal is accepted (seconded with no objections)
api-change-proposal
A proposal to add or alter unstable APIs in the standard libraries
T-libs-api
Proposal
Problem statement
the current behavior of
set_permissions
can lead to privilege escilations such as in CVE-2025-27591.Motivating examples or use cases
Privileged software that wishes to set up a world-writable directory without potentially making other directories world-writable
Solution sketch
add
set_symlink_permissions
, a function that attempts to set the permissions of a file or directory without following any symlinks.on linux, this will simply fail when used on a symlink, however on BSD systems it can use
lchmod
.Alternatives
std::fs::set_permissions
without an edition boundary.set_permissions_nofollow
which always fails when used on a symlinkFuture Possibilites
if we get edition-dependent aliases, set_permissions could be changed to point to this in a future edition.
Links and related work
What happens now?
This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
Second, if there's a concrete solution:
The text was updated successfully, but these errors were encountered: