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
I'm trying to implement some logic that extracts a zip file using cap-primitives and ran into a snag with how fs::set_permissions is currently implemented. In the general UNIX implementation it says even AT_NOFOLLOW_SYMLINK with fchmodat is not enough because it would modify the symlink itself, and that it is undesirable behavior. So, because of that, its implemented as a regular fchmod. Its not clear to me why this is undesirable at a glance though.
In my case however, I am actually trying to change the symlink itself based on permission bits that come from the zip file and the current behavior makes that impossible as it always dereferences the symlink and changes the permissions of the linked item instead. This is an odd use case, but I have the constraint of the process umask set at startup being more restrictive then what the zipped file permissions are, so I need to change everything written out to disk after writing to get the correct resulting permissions.
Is this a feature that you would consider adding to cap-primitives, or is "weird" symlink handling something that's considered out-of-scope?
The text was updated successfully, but these errors were encountered:
cap-std's public set_permissions function follows Rust's std's set_permission function which always follows symlinks. So all of cap-std's code related to setting permissions is assuming that the user has requested us to follow symlinks, and that this must be done manually so that we don't follow symlinks outside of the sandbox.
If you wanted to add the ability to set the permissions of a symlink itself, you'd need to add a new public API for that, named something like set_symlink_permissions or so. Note that not all platforms can support this. Notably, Linux does not support this at all. So you could add it to cap-primitives, and expose the public API in the cap-fs-ext crate via an extension trait, rather than the cap-std crate. This functionality is not a priority for any of my own use cases, but I'd accept a PR adding it.
Hello 👋,
I'm trying to implement some logic that extracts a zip file using
cap-primitives
and ran into a snag with howfs::set_permissions
is currently implemented. In the general UNIX implementation it says evenAT_NOFOLLOW_SYMLINK
withfchmodat
is not enough because it would modify the symlink itself, and that it is undesirable behavior. So, because of that, its implemented as a regularfchmod
. Its not clear to me why this is undesirable at a glance though.In my case however, I am actually trying to change the symlink itself based on permission bits that come from the zip file and the current behavior makes that impossible as it always dereferences the symlink and changes the permissions of the linked item instead. This is an odd use case, but I have the constraint of the process
umask
set at startup being more restrictive then what the zipped file permissions are, so I need to change everything written out to disk after writing to get the correct resulting permissions.Is this a feature that you would consider adding to
cap-primitives
, or is "weird" symlink handling something that's considered out-of-scope?The text was updated successfully, but these errors were encountered: