Skip to content

Something a bit like CheckedDir but a bit like StateMgr

Example use case. Replace these three arguments to OnionService::new with a single argument:

        statemgr: S,
        state_dir: &Path,
        state_mistrust: &fs_mistrust::Mistrust,

CheckedDir has some of the necessary pieces. It is not suitable because: it is quite unergonomic; and, it encapsulates a "needs to be private" boolean (which wants to vary according to the particular use, so ought not to be present here).

tor_persist::FsStateMgr also has some of the necessary pieces. But it is not suitable because: it is just for the json file storage arragements, and doesn't give access to the underlying filesystem path; and, its locking behaviour is unsuitable.

The type to use here should have the following properties:

  • It should embody a PathBuf (and possibly other info) and be 'static.
  • Using it should ensure that appropriate fs_mistrust checks are done (see below)
  • Locking against concurrent use should be included as a feature, and exclusive access should be part of the type (not a runtime property)
  • It should be possible to get a DynStorageHandle (or similar within it).
  • It should be possible to get Path and PathBuf within it.
  • Probably it should be possible to get the inner PathBuf (maybe with an _unchecked name on the method).
  • Presumably, the users are to supply the subpath or subdirectory, and are responsible for ensuring these subdirs are unique across every user. For example, it's the job of tor-hsservice to include both "hs" and the HS nickname in subpaths.

Open questions:

  1. Are we going to use this for cache_dir too? If so should the type imply that the thing is, ultimately, state_dir? Ie should there be a type parameter for that? Perhaps that's overkill and we can just have the different variable names state_dir and cache_dir (many users have little use for a cache_dir).
  2. Should mistrust checking be done (a) when this thing is created from [storage.permissions] and state_dir or (b) when it is used (or both)? I think favour (a), which implies that the mistrust check is done during startup and individual sub-directories are not mistrust-checked; except that we need to handle need-to-be-private directories too, which could only be done with (b).
  3. Can we use this for the keymgr? I think using it for the keymgr might help with #1162, but certainly we should consider the interaction.