Nix 2.28.3
Nix, the purely functional package manager; unstable internal interfaces
 
Loading...
Searching...
No Matches
nix::MountedSSHStore Class Reference
Inheritance diagram for nix::MountedSSHStore:
nix::SSHStore

Public Member Functions

 MountedSSHStore (std::string_view scheme, std::string_view host, const Params &params)
 
std::string getUri () override
 
void narFromPath (const StorePath &path, Sink &sink) override
 
ref< SourceAccessor > getFSAccessor (bool requireValidPath) override
 
std::optional< std::string > getBuildLogExact (const StorePath &path) override
 
Path addPermRoot (const StorePath &path, const Path &gcRoot) override
 
- Public Member Functions inherited from nix::SSHStore
 SSHStore (std::string_view scheme, std::string_view host, const Params &params)
 
std::string getUri () override
 
std::optional< std::string > getBuildLogExact (const StorePath &path) override
 

Additional Inherited Members

- Protected Member Functions inherited from nix::SSHStore
ref< RemoteStore::Connection > openConnection () override
 
void setOptions (RemoteStore::Connection &conn) override
 
- Protected Attributes inherited from nix::SSHStore
std::string host
 
std::vector< std::string > extraRemoteProgramArgs
 
SSHMaster master
 

Detailed Description

The mounted ssh store assumes that filesystems on the remote host are shared with the local host. This means that the remote nix store is available locally and is therefore treated as a local filesystem store.

MountedSSHStore is very similar to UDSRemoteStore — ignoring the superficial differnce of SSH vs Unix domain sockets, they both are accessing remote stores, and they both assume the store will be mounted in the local filesystem.

The difference lies in how they manage GC roots. See addPermRoot below for details.

Member Function Documentation

◆ addPermRoot()

Path nix::MountedSSHStore::addPermRoot ( const StorePath & path,
const Path & gcRoot )
inlineoverride

This is the key difference from UDSRemoteStore: UDSRemote store has the client create the direct root, and the remote side create the indirect root.

We could also do that, but the race conditions (will the remote side see the direct root the client made?) seems bigger.

In addition, the remote-side will have a process associated with the authenticating user handling the connection (even if there is a system-wide daemon or similar). This process can safely make the direct and indirect roots without there being such a risk of privilege escalation / symlinks in directories owned by the originating requester that they cannot delete.


The documentation for this class was generated from the following file: