Second cut at a fs-mistrust crate.
- May 03, 2022
-
-
Nick Mathewson authored -
Nick Mathewson authored
-
Nick Mathewson authored
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.
-
Nick Mathewson authored
This will make a "trust_everyone" easier to implement.
-
Nick Mathewson authored
-
Nick Mathewson authored
Some of our builders put root into gid 0, but getgroups() doesn't actually give any result.
-
Nick Mathewson authored
This required a bit of poking through the `users` crate, to mess with the user and group dbs. The original goal was to "trust the group with the same name as us", but it turned into a bit of a production, since: * We want to take our own name from $USER, assuming that matches our uid. (Otherwise we want to ask getpwuid_r().) * We only want to trust the group if we are actually a member of that group. * We want to cache this information. * We want to test this code. -
Nick Mathewson authored
Previously we would temporarily put self.resolved into an invalid state by adding a path component that might be a symlink. With this change, we create a new temporary path object (using Cow to avoid unnecessary allocations) and only conditionally replace self.resolved.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
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.
-
Nick Mathewson authored
Also, explain _why_ this is pretty important.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
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.
-