Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved support for changing symlink permissions #283

Open
complexspaces opened this issue Nov 16, 2022 · 1 comment
Open

Improved support for changing symlink permissions #283

complexspaces opened this issue Nov 16, 2022 · 1 comment

Comments

@complexspaces
Copy link

Hello 👋,

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?

@sunfishcode
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants