Mounting a single file fails silently

[comunidadio]

Description

Steps to Reproduce

➜  matchlocktesting ls
1file.txt
➜  matchlocktesting matchlock run --image alpine:latest --rm -v ./1file.txt:/workspace/1file.txt -it sh
➜  matchlocktesting

Expected Behaviour

Single file mounting works. This is useful for things like $SSH_AUTH_SOCK (forwarding host's SSH agent to guest).

Actual Behaviour

Match lock just exits silently (with exit code though but wasn't immediately obvious).

Environment

• OS: macOS 15.7.3
• Architecture: arm64
• Matchlock version: 0.1.12

[jingkaihe]

@comunidadio Thanks for reporting, will look into the issue(s). Apologises for the earlier comment spams - I asked agent for initial issue triage, and it went ahead and posted them (which tend to be more noise than signal)

[jingkaihe]

Single file mount is now supported (it worked in the past but somehow regressed due to lacking acceptance test for this)

That said$SSH_AUTH_SOCK hasn't been tested yet, likely not working right now because technically the listening socket is in the host kernel namespace. Also the socket file is mounted as a file, therefore the socket inode will be lost.

I was considering supporting this, however the only use cases I can think of is github clone over ssh, which can be worked around via forwarding GITHUB_TOKEN as env var into the sandbox.

That said, feel free to raise a separate issue, with use cases for it.

[comunidadio]

One thing I noticed not sure if intended, the VM's default working directory is now / instead of /workspace ?

[comunidadio]

That said$SSH_AUTH_SOCK hasn't been tested yet, likely not working right now because technically the listening socket is in the host kernel namespace.

Yeah, getting can't open '/workspace/.ssh.sock': I/O error.

But regular files work fine 👍

I was considering supporting this, however the only use cases I can think of is github clone over ssh, which can be worked around via forwarding GITHUB_TOKEN as env var into the sandbox.

Fair enough, that's probably the main use case indeed, and the one I was immediately after. I'll check if GITHUB_TOKEN works for my use case.

That said, it would be so interesting to have agent-controlled matchlock do SSH requests to other machines, mediated by the host 🙃 (so the given selected SSH key is still secret inside the VM, similarly to the MITM HTTPS secrets)