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

should std::path not requirefs permission ? #12

Open
sigmaSd opened this issue Oct 11, 2023 · 1 comment
Open

should std::path not requirefs permission ? #12

sigmaSd opened this issue Oct 11, 2023 · 1 comment

Comments

@sigmaSd
Copy link

sigmaSd commented Oct 11, 2023

I feel like this is not needed, I expected fs permission for only manipulating files like reads/writes etc, but requires fs permission just for creating paths from strings seems to much in my opinion.

@sigmaSd sigmaSd changed the title should std::path be not requirefs permission ? should std::path not requirefs permission ? Oct 11, 2023
@davidlattimore
Copy link
Collaborator

Probably you're right. I've erred on the side of overclassifying rather than risking underclassifying. I think I probably need a more foolproof method to determine which functions actually access files to make sure I don't miss any. One way I've been considering is by disassembling functions to look for syscalls, then working back from there to determine what functions use each API.

In the meantime, if you delete (or rename) your cackle.toml, then run cargo acl again and select "Create custom initial config", you'll be able to inline each API definition rather than importing them. That will give you the chance to edit them. It also means that if the built-in API definitions change, you won't get those new API definitions which is maybe good, maybe bad. If you do come up with some alternative API definitions that you think are better than the ones currently built into cackle, I'd be open to integrating them.

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