vincenzopalazzo
/
arti
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
arti/crates/fs-mistrust/Cargo.toml

43 lines
1.2 KiB
TOML
Raw Normal View History

Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
[package]
name = "fs-mistrust"
Bump crate versions in preparation for v1.1.5 release. Generated with the following commands: ``` cargo set-version --bump minor -p tor-cell cargo set-version --bump minor -p tor-linkspec cargo set-version --bump minor -p tor-proto cargo set-version --bump minor -p tor-netdoc cargo set-version --bump minor -p tor-circmgr cargo set-version --bump patch -p tor-cert cargo set-version --bump patch -p tor-basic-utils cargo set-version --bump patch -p tor-rpcbase cargo set-version --bump patch -p tor-llcrypto cargo set-version --bump patch -p tor-hscrypto cargo set-version --bump patch -p tor-checkable cargo set-version --bump patch -p tor-async-utils cargo set-version --bump patch -p caret cargo set-version --bump patch -p fs-mistrust cargo set-version --bump patch -p safelog cargo set-version --bump patch -p retry-error cargo set-version --bump patch -p tor-error cargo set-version --bump patch -p tor-config cargo set-version --bump patch -p tor-events cargo set-version --bump patch -p tor-units cargo set-version --bump patch -p tor-rtcompat cargo set-version --bump patch -p tor-rtmock cargo set-version --bump patch -p tor-protover cargo set-version --bump patch -p tor-bytes cargo set-version --bump patch -p tor-socksproto cargo set-version --bump patch -p tor-consdiff cargo set-version --bump patch -p tor-netdir cargo set-version --bump patch -p tor-congestion cargo set-version --bump patch -p tor-persist cargo set-version --bump patch -p tor-chanmgr cargo set-version --bump patch -p tor-ptmgr cargo set-version --bump patch -p tor-guardmgr cargo set-version --bump patch -p tor-dirclient cargo set-version --bump patch -p tor-dirmgr cargo set-version --bump patch -p tor-hsclient cargo set-version --bump patch -p tor-hsservice cargo set-version --bump patch -p arti-client cargo set-version --bump patch -p arti-rpcserver cargo set-version --bump patch -p arti-config cargo set-version --bump patch -p arti-hyper cargo set-version --bump patch -p arti cargo set-version --bump patch -p arti-bench cargo set-version --bump patch -p arti-testing ```
2023-06-01 15:03:05 +01:00
version = "0.7.1"
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
authors = ["The Tor Project, Inc.", "Nick Mathewson <nickm@torproject.org>"]
set all crate edition to 2021
2022-10-31 23:06:13 +00:00
edition = "2021"
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
license = "MIT OR Apache-2.0"
homepage = "https://gitlab.torproject.org/tpo/core/arti/-/wikis/home"
description = "Ensure that files can only be read or written by trusted users"
keywords = ["fs", "file", "permissions", "ownership", "privacy"]
categories = ["filesystem"]
repository = "https://gitlab.torproject.org/tpo/core/arti.git/"
Increment MSRV to 1.65 in every crate.
2023-04-11 20:31:12 +01:00
rust-version = "1.65"
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
Add functionality to inspect directory content permissions Also, explain _why_ this is pretty important.
2022-04-19 01:23:23 +01:00
[features]
fs-mistrust: Add a `anonymize_home` extension fn for Path. This function transforms `/home/nickm/.config` to `${HOME}/.config/`, so that we can expose the username less in our logs.
2022-08-26 14:06:23 +01:00
default = ["walkdir", "anon_home"]
Revise all XXXXs from fixup-features
2023-05-15 16:00:28 +01:00
full = ["walkdir", "anon_home"]
fs-mistrust: Add a `anonymize_home` extension fn for Path. This function transforms `/home/nickm/.config` to `${HOME}/.config/`, so that we can expose the username less in our logs.
2022-08-26 14:06:23 +01:00
anon_home = ["once_cell", "dirs"]
Add functionality to inspect directory content permissions Also, explain _why_ this is pretty important.
2022-04-19 01:23:23 +01:00
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
[dependencies]
fs-mistrust: make Mistrust have a corresponding Builder type. This is an approximately minimal revision to get Builder in place; subsequent commits will clean up the API.
2022-05-18 18:26:01 +01:00
derive_builder = { version = "0.11", package = "derive_builder_fork_arti" }
Bump to the lastest versions of dirs and directories.
2023-03-22 19:15:42 +00:00
dirs = { version = "5", optional = true }
fs-mistrust: Add Group and User types. This will help make the actual configuration more serializable, I hope.
2022-05-18 19:36:24 +01:00
educe = "0.4.6"
fs-mistrust: Add a `anonymize_home` extension fn for Path. This function transforms `/home/nickm/.config` to `${HOME}/.config/`, so that we can expose the username less in our logs.
2022-08-26 14:06:23 +01:00
once_cell = { version = "1", optional = true }
Lexically sort Cargo.toml dependencies Utilize cargo-sort: https://github.com/DevinR528/cargo-sort Signed-off-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
2022-05-28 17:41:39 +01:00
serde = { version = "1.0.103", features = ["derive"], optional = true }
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
thiserror = "1"
Add functionality to inspect directory content permissions Also, explain _why_ this is pretty important.
2022-04-19 01:23:23 +01:00
walkdir = { version = "2", optional = true }
Add serde derives for MistrustBuilder. The Group and User (de)serialization is pretty ugly, and I can't vouch for the correcness of MistrustBuilder. I will seek feedback before I proceed.
2022-05-18 21:29:23 +01:00
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
[target.'cfg(unix)'.dependencies]
libc = "0.2"
fs-mistrust: Add code to make a self-named group "trusted". 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.
2022-04-27 20:20:56 +01:00
once_cell = "1"
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
fix fs-misstrust on android 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
2022-08-08 21:32:07 +01:00
[target.'cfg(all(unix, not(target_os="ios"), not(target_os="android")))'.dependencies]
remove dependancy 'users' on iOS
2022-07-30 10:28:03 +01:00
users = "0.11"
Second cut at a fs-mistrust crate. 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.
2022-04-13 16:32:23 +01:00
[dev-dependencies]
Write custom serde impls for Trusted{User,Group} We support all of the following (in TOML notation): ``` user = "rose" # by name user = 413 # by ID user = false # no user user = ":current" # A 'special' user. user = { name: "rose" } user = { id: 413 } user = { special: ":none" } user = { special: ":current" } ```
2022-05-20 20:15:56 +01:00
serde_json = "1.0.50"
fs-mistrust: more examples, documentation.
2022-04-24 16:12:45 +01:00
tempfile = "3"
Upgrade to latest toml crate. (None of the breaking changes affect us this time.)
2023-02-14 16:05:48 +00:00
toml = "0.7.2"
enable doc_auto_cfg feature on every crate when documenting for docs.rs
2022-08-17 20:13:13 +01:00
[package.metadata.docs.rs]
all-features = true
rustdoc-args = ["--cfg", "docsrs"]