Permissions for --ssh mounted sockets -- am I doing something wrong here?

[njvack]

Hey there,

I'm experimenting with container for using AI agents for dev (more) safely. To this end, I'd like to be able to:

• Have my SSH agent forwarding work "nicely"
• Limit my mounts to things I have chosen; I don't want my container to be able to see all of $HOME
• Not be root in the container -- I'll be deploying in environments with normal permissions, so I don't really want to develop as root

I can use plain old container run --ssh and that maps my socket into /var/host-services/ssh-auth.sock -- but my normal user can't read it:

ls -l /var/host-services/ssh-auth.sock
srw------- 1 root root 0 Jun 19 15:51 /var/host-services/ssh-auth.sock

I have a workaround involving the container starting as root and using a custom ENTRYPOINT script that does:

socat UNIX-LISTEN:/tmp/ssh-agent.sock,fork,mode=666 \
  UNIX-CONNECT:/run/host-services/ssh-auth.sock &

... which connects a second socket with more favorable permissions, and then execs a login shell as my non-root user, but woof

container machine does user mapping and sets up the SSH socket perfectly (/var/host-services/ssh-auth.sock is owned by my non-root user, yay!), but alas, I have all of $HOME right there.

I read PR #1751 which suggests other sockets should get the same permission mapping as the ones connected by --ssh, not that the ssh ones are wrong. So I feel like this is probably on my end, not on container but...? FWIW, I can build an image using this Dockerfile:

FROM ubuntu:resolute
RUN useradd --uid 501 --create-home --groups staff --no-user-group njvack
USER njvack

and then:

$ container run --ssh -it --rm sshtest sh -c 'echo $SSH_AUTH_SOCK && ls -l $SSH_AUTH_SOCK && whoami'
/var/host-services/ssh-auth.sock
srw------- 1 root root 0 Jun 19 16:13 /var/host-services/ssh-auth.sock
njvack

[njvack]

okay so socat was a little bit silly; chmod 666 "$SSH_AUTH_SOCK" gets the job done a bit better

But this still seems like I'm missing something here; I shouldn't need a custom entrypoint script to do this, right?

[multigl]

I think you might, I was also only able to resolve this in my own custom entry point script, but instead of a chmod I chown to the user in the container I needed.

[jglogan]

@njvack Can you try this with 1.1.0 or newer?

Dockerfile:

FROM alpine:latest

RUN apk add --no-cache openssh-client

USER guest

CMD ["/bin/sh"]

container build -t test -f Dockerfile .
container run -v "${SSH_AUTH_SOCK}:/var/host-services/ssh-auth.sock" ls -l /var/host-services/ssh-auth.sock
container run -v "${SSH_AUTH_SOCK}:/var/host-services/ssh-auth.sock" -e SSH_AUTH_SOCK=/var/host-services/ssh-auth.sock test ssh-add -l

The #1751 fix means that I see this for the ls -l command:

srw-rw-rw-    1 root     root             0 Jul 29 16:27 /run/ssh-auth.sock

And for the ssh-add -l command I see my ssh key fingerprints.

The --ssh option and the pair of -v and -e are more or less equivalent, except --ssh adjusts the value of SSH_AUTH_SOCK each time the container starts, to handle the case where the environment variable changes (such as when you log out and log back in).