Skip to main content

FilesystemProbe

runner_manager_platform::runner_root

Trait FilesystemProbe 

Source 
pub trait FilesystemProbe {
    // Required methods
    fn identify(&self, directory: &Path) -> Result<FilesystemIdentity>;
    fn is_writable(&self, directory: &Path) -> Result<bool>;

    // Provided methods
    fn runs_as_superuser(&self) -> bool { ... }
    fn is_on_privacy_gated_volume(&self, directory: &Path) -> bool { ... }
    fn is_read_only(&self, directory: &Path) -> bool { ... }
}
Expand description

The two questions the preflight asks the operating system.

A trait rather than two free functions because a network share and a directory this account may not write are not things a test may create: one needs a file server and the other needs an account that is not the one running the suite. 04-security-recovery.md requires “table-driven cross-platform validator tests” for exactly those cases, so the seam is part of the design rather than a testing afterthought. HostFilesystem is the real implementation and is what every production caller gets.

Required Methods§

Source

fn identify(&self, directory: &Path) -> Result<FilesystemIdentity>

The filesystem directory — which exists — sits on.

§Errors

Whatever the platform reported.

Source

fn is_writable(&self, directory: &Path) -> Result<bool>

Whether this account may create entries in directory, which exists.

Implementations must answer without creating, deleting, or re-permissioning anything.

§Errors

Whatever the platform reported, other than a plain refusal.

Provided Methods§

Source

fn runs_as_superuser(&self) -> bool

Whether this process runs with an identity that file permissions cannot refuse.

Asked only to classify a refusal that has already happened, and it is on this trait rather than beside it because it is the same kind of question as the other two – something only the operating system can answer, and something a test may not arrange for itself: the suite cannot become root to prove what root is told. The default is the real answer, so every existing implementation keeps working unchanged.

Source

fn is_on_privacy_gated_volume(&self, directory: &Path) -> bool

Whether directory is on a volume the platform’s privacy layer gates.

Here for the same reason as FilesystemProbe::runs_as_superuser: the suite cannot mount an external disk to ask. The default is the real answer.

Source

fn is_read_only(&self, directory: &Path) -> bool

Whether directory is on a filesystem mounted read-only.

Asked because FilesystemProbe::is_writable cannot answer it: it collapses EACCES, EPERM and EROFS into one false, so by the time a refusal is classified the difference between “this account may not” and “nobody may, the volume is read-only” is gone. A read-only mount refuses a superuser for an entirely ordinary reason, and a read-only disk image mounts under /Volumes like any other – so without this the privacy branch below would blame consent for EROFS.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§