Skip to content
Snippets Groups Projects

Second cut at a fs-mistrust crate.

Merged Nick Mathewson requested to merge nickm/arti:fs-mistrust-v2 into main

This crate is meant to solve #315 (closed) 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.

This is part of #315 (closed), but not yet a complete implementation, since the fs-mistrust crate is not yet used.

Edited by Nick Mathewson

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • eta
  • eta
  • eta
  • eta
  • eta approved this merge request

    approved this merge request

  • Contributor

    This looks good to me, modulo a few comments. I don't consider myself an expert on Unix filesystems by any means, so I think it's a good idea to get @Diziet to do another pass over it just to double-check there aren't any glaringly obvious security flaws.

  • Contributor

    Oh wait, just realised I only did one commit. Gimme a sec...

  • eta unapproved this merge request

    unapproved this merge request

  • eta
  • eta
  • eta approved this merge request

    approved this merge request

  • Contributor

    (Review is now complete.)

  • Ian Jackson
    Ian Jackson @Diziet started a thread on commit d42e243f
  • 91 Error::StepsExceeded => return None,
    92 Error::CurrentDirectory(_) => return None,
    93 }
    94 .as_path(),
    95 )
    96 }
    97
    98 /// Return an iterator over all of the errors contained in this Error.
    99 ///
    100 /// If this is a singleton, the iterator returns only a single element.
    101 /// Otherwise, it returns all the elements inside the `Error::Multiple`
    102 /// variant.
    103 ///
    104 /// Does not recurse, since we do not create nested instances of
    105 /// `Error::Multiple`.
    106 pub fn errors<'a>(&'a self) -> impl Iterator<Item = &Error> + 'a {
    • Suggested change
      131 pub fn errors<'a>(&'a self) -> impl Iterator<Item = &Error> + 'a {
      131 #[must_use]
      132 pub fn errors<'a>(&'a self) -> impl Iterator<Item = &Error> + 'a {
    • Please register or sign in to reply
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading