Credential-enhanced operations via FODs #951

New issue

Open

opened 2025-08-04 14:48:43 +00:00 by raito · 0 comments

raito commented

2025-08-04 14:48:43 +00:00

Owner

Credential-enhanced operations like git clone to an SSH target might require private key material, e.g. an SSH key.
Unfortunately, the usual solution which involve to perform fetchgit { prefetch = "export GIT_SSH_COMMAND="ssh -i /some/place""; url = "..."; } won't work with --extra-sandbox-paths because an SSH keys is usually defended with permissions.

extra-sandbox-paths performs a naive bind mount which results into a nobody:nogroup inode which cannot be read.

Describe the solution you'd like

(1) Guidance on how to do these sorts of things: why pick builtins.fetchGit vs. pkgs.fetchgit in these circumstances. Why pick SSH over HTTPS, etc.
(2) It would be interesting to think about how we could map such inodes which are accessible to the daemon and the caller inside the sandbox as well, but this is a certain can of worm.

Describe alternatives you've considered

(1) chmod a+r the SSH key.
(2) Make a socket server which give you the SSH key by identifying the caller PID via SCM_RIGHTS (maybe the best solution).

Additional context

Sparked from a discussion where someone needed to use fetchLFS = true; but could not with builtins.fetchGit as Lix plausibly did not enable this possibility.

## Is your feature request related to a problem? Please describe. Credential-enhanced operations like `git clone` to an SSH target might require private key material, e.g. an SSH key. Unfortunately, the usual solution which involve to perform `fetchgit { prefetch = "export GIT_SSH_COMMAND="ssh -i /some/place""; url = "..."; }` won't work with `--extra-sandbox-paths` because an SSH keys is usually defended with permissions. `extra-sandbox-paths` performs a naive bind mount which results into a `nobody:nogroup` inode which cannot be read. ## Describe the solution you'd like (1) Guidance on how to do these sorts of things: why pick `builtins.fetchGit` vs. `pkgs.fetchgit` in these circumstances. Why pick SSH over HTTPS, etc. (2) It would be interesting to think about how we could map such inodes which are accessible to the daemon and the caller inside the sandbox as well, but this is a certain can of worm. ## Describe alternatives you've considered (1) `chmod a+r` the SSH key. (2) Make a socket server which give you the SSH key by identifying the caller PID via SCM_RIGHTS (maybe the best solution). ## Additional context Sparked from a discussion where someone needed to use `fetchLFS = true;` but could not with `builtins.fetchGit` as Lix plausibly did not enable this possibility.