summaryrefslogtreecommitdiff
path: root/crates/fs-mistrust/src/imp.rs
Commit message (Collapse)AuthorAgeFilesLines
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-071-1/+1
| | | | | | | | | | | | | | First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.
* Update code for Edition 2024Nick Mathewson2025-08-071-2/+5
| | | | | | | | | | | | | | | | | | 1. Run cargo fix --edition 2. Selectively revert the "if let"->"match" changes. These changes are meant to protect us from the lifetime changes for "if let" bindings in Rust 2024. But we're not actually relying on the old lifetime rules anywhere, and the match syntax here is quite ugly. 3. Automatically revert `$pat:expr_2021` to `$pat:expr`. (We don't actually want to restrict the expression syntax that our macros accept). Done with `git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'` 4. Run cargo fmt.
* fix compiling fs-misstrust on tvOSyaucp2025-03-261-3/+11
|
* fix fs-misstrust on androidtrinity-1686a2022-08-081-5/+14
| | | | | | it would fail to link at runtime due to missing getgrnam_r in bionic and then it would fail again because some directory is group writeable
* fix runtime issues on iostrinity-1686a2022-07-301-2/+7
|
* remove dependancy 'users' on iOStrinity-1686a2022-07-301-3/+13
|
* fs-mistrust: API to disable based on environmentNick Mathewson2022-07-191-2/+2
| | | | | | | By default we look at `$FS_MISTRUST_DISABLE_PERMISSIONS_CHECKS`. Optionally, the user can provide another variable as well, or disable looking at the environment entirely.
* fs-mistrust: Improve BadPermission stringAlex Xu (Hello71)2022-05-311-1/+5
| | | | | | | | | To me, "Incorrect permissions on file or directory /path: g=w o=w" implies that the current permissions on /path are 022. Change the message to "Incorrect permissions: /path is u=rwx,g=rwx,o=rwx; need g-w,o-w", which is closer to chmod syntax and is more useful in non-interactive environments such as CI and support.
* fs-mistrust: allow symlinks to have any permissionsAlex Xu (Hello71)2022-05-251-0/+8
|
* fs-mistrust: rename fieldsNick Mathewson2022-05-241-4/+4
| | | | | This renaming will make things slightly simpler for declaring a builder.
* Loosen checking for readable files within target directories.Nick Mathewson2022-05-091-10/+13
| | | | | | | | | | | | | | | If the target directory itself is unreadable by untrusted users, then its contents can't be read[*] by them regardless of their permissions. If the target directory _is_ readable, then _it_ will be rejected if we are forbidding readable objects. (And if we aren't we don't care if the contents are readable.) A similar argument would apply to writable objects within an unreadable target directory. We're not making that argument, since such contents are likelier to be a mistake. [*] Unless they're hard-linked; see comments in "Limitations" section.
* fs-mistrust: write a lot about TOCTOU issues.Nick Mathewson2022-05-031-5/+6
|
* fs-mistrust: Add a dangerously_trust_everyone method.Nick Mathewson2022-05-031-1/+14
| | | | | | | This helps make it possible to use `SecureDir` (name pending) even when we want to disable permissions checks. Otherwise, optional permission checking would require users of this crate to maintain separate code paths for the "check" and "don't check" cases.
* fs-mistrust: split check_one into two functions.Nick Mathewson2022-05-031-46/+64
| | | | This will make a "trust_everyone" easier to implement.
* Add a must_use (suggested by @diziet).Nick Mathewson2022-05-031-0/+1
|
* Add a SecureDir API for checked access to directoriesNick Mathewson2022-05-031-1/+6
| | | | | | The only way to get a SecureDir is by having checked a directory. Once you have one, it encourages you to open and create files and directories with the right permissions, and checks them for you.
* Add functionality to inspect directory content permissionsNick Mathewson2022-05-031-24/+55
| | | | Also, explain _why_ this is pretty important.
* By default, forbid special files.Nick Mathewson2022-05-031-11/+20
|
* Add support for trusted group IDs.Nick Mathewson2022-05-031-1/+5
|
* Implement support for the Sticky Bit.Nick Mathewson2022-05-031-3/+27
|
* Second cut at a fs-mistrust crate.Nick Mathewson2022-05-031-0/+126
This crate is meant to solve #315 by giving a way to make sure that a file or directory is only accessible by trusted users. I've tried to explain carefully (in comments and documentation) what this crate is doing and why, under the assumption that it will someday be read by another person like me who does _not_ live and breathe unix file permissions. The crate is still missing some key features, noted in the TODO section. It differs from the first version of the crate by taking a more principled approach to directory checking: it emulates the path lookup process (reading symlinks and all) one path change at a time, thus ensuring that we check every directory which could enable an untrusted user to get to our target file, _or_ which could enable them to get to any symlink that would get them to the target file. The API is also slightly different: It separates the `Mistrust` object (where you configure what you do or do not trust) from the `Verifier` (where you set up a check that you want to perform on a single object). Verifiers are set up to be a bit ephemeral, so that it is hard to accidentally declare that _every_ object is meant to be readable when you only mean that _some_ objects may be readable.