std::fs::symlink_metadata + set_permissions makes unintuitive behavior

[youknowone]

Location

std::fs::symlink_metadata or std::fs::set_permissions

Summary

fn main() -> std::io::Result<()> {
  use std::os::unix::fs::PermissionsExt;

  let path = std::path::PathBuf::from("bar");   // `bar` is a symlink
  let meta = std::fs::symlink_metadata(&path)?;
  let mut permissions = meta.permissions();
  println!("current mode: {:o}", permissions.mode());
  permissions.set_mode(0o707);
  println!("new mode: {:o}", permissions.mode());

  std::fs::set_permissions(&path, permissions)?;  // applied permission to original file

  let meta = std::fs::symlink_metadata(&path)?;
  let mut permissions = meta.permissions();
  println!("reloaded mode: {:o}", permissions.mode());
  Ok(())
}

current mode: 120755
new mode: 707
reloaded mode: 120755

Since I could obtain metadata for either original file or symlink, I expected there must be a way to apply permissions to symlink. But symlink_metadata revealed not to have a pair of set_permissions.

By the design if it is intended or lack of API, it could be documented somewhere like symlink_metadata or set_permissions.

On the other hand, metadata is obtainable from either file or symlink. Then I expected set_permission to be placed on metadata object if metadata includes symlink information.
e.g. metadata.set_permissions(path, permissions)

[the8472]

symlink permissions have no effect or can't be set on most unixes, therefore setting them does not make sense as a portable API.

https://superuser.com/a/1188707

[youknowone]

I agree that point. macOS and a few more BSDs are affect by this. Adding a short warning will make sense.

[lolbinarycat]

both versions of set_permissions should have a warning about their interactions with symlinks, as this mistake lead to CVE-2025-27591.

[lolbinarycat]

perhaps it would even be worth making a set_permissions_nofollow that fails if it is used on a symlink, to avoid repeating this vulnerability.

[youknowone]

Thanks @lolbinarycat