Custom vsock sockets can prevent attaching interactive (-i) commands

[valpackett]

If you manually expose some host service via vsock by creating a DYNAMIC_PORT_RANGE socket (say we just go with the first available one, krun/socket/port-50000)…

muvm -it bash just doesn't work with a cryptic error:

Error: could not request launch to server: Failed to listen on vm socket

Because acquire_socket_lock() only checks for the existence of port-{port}.lock lockfiles it itself creates… and advisory locks on them… so it sees no .lock and tries to touch the occupied socket itself…

statx(AT_FDCWD, "/run/user/10000/krun/socket/port-50000.lock", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
openat(AT_FDCWD, "/run/user/10000/krun/socket/port-50000.lock", O_RDWR|O_CLOEXEC) = 3
flock(3, LOCK_EX|LOCK_NB)               = 0
unlinkat(AT_FDCWD, "/run/user/10000/krun/socket/port-50000", 0) = -1 EBUSY (Device or resource busy)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
bind(4, {sa_family=AF_UNIX, sun_path="/run/user/10000/krun/socket/port-50000"}, 41) = -1 EADDRINUSE (Address already in use)

Having to do the lock for an external service is kind of a lot, and it's not documented— well, not like the entire feature is documented outside of PRs/issues :) buuut still.