Nix 2.29.0
Nix, the purely functional package manager; unstable internal interfaces
|
Public Types | |
using | Config = MountedSSHStoreConfig |
Public Types inherited from nix::SSHStore | |
using | Config = SSHStoreConfig |
Public Member Functions | |
MountedSSHStore (ref< const Config > config) | |
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 (ref< const Config > config) | |
std::string | getUri () override |
std::optional< std::string > | getBuildLogExact (const StorePath &path) override |
Additional Inherited Members | |
Public Attributes inherited from nix::SSHStore | |
ref< const Config > | config |
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 |
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.
|
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.