Remote Containers: Design Bug or missdocumented feature: lack of affinity.

[PavelSosin-320]

When Remote Container is created by VSCode it doesn't establish the affinity with the remote container.Affinity is the known pattern that must be implemented in any case when the client creates remote object managed by a separate orchestration mechanism like Docker daemon. The client which owns the remote object can be able to monitor, inspect, and manage his objects, i.e. container but only his objects. Docker run command intentionally speels ID of every created container into PID file when --PID option is provided. This PID must be used for all further interactions with container. The knowledge of PID makes the client the exclusive owner of the container. The PID can be achieved also via docker --last/latest ps Any attempt of access to the container should be blocked unless container is in running state This is also a good practice to check the remote status periodically and restore it if it went down. Other non-desktop IDEs do such polling with teeth greeting with interval defined by the container only to keep connection with remote container alive.

• VSCode Version: 2.44.2
• Local OS Version: Windows 10 Pro 2004 dev preview
• Remote OS Version: Same machine
• Remote WSL / Docker Desktop 2.2.3 Steps to Reproduce:
  1. Install Stack like at my machine
  2. Install corresponding VSCode version
  3. Start VSCode Remote Dev container
  4. Check your container status if you know how
  5. Inspect tour Container if you know how
  6. Restart your container if you know how

     Does this issue occur when you try this locally?: Yes, on local Docker engine Does this issue occur when you try this locally and all extensions are disabled?: Extension specific P.S. Lack of backward Affinity is a security issue - the container must reject all attempts to attach/ssh if the Client is not the owner.

[chrmarti]

Not sure I understand, neither --PID nor --cidfile would help with isolation/security or am I missing something?

[PavelSosin-320]

No, this is a normal way to work with containers. It works out-the-box for any user in Shell/Powershell and it is a fundamental Cloud concept implemented by all container orchestration systems: Docker container is a manageable object and if it is stateful owner must keep persistent handler - PID file to manage it: Then you can docker inspect $myContainerPid docker logs $myContainerPid docker attach $myContainerPid$myContainerPid docker restart $myContainerPid Split between docker pull and create is very important because pull creates shared attract and create allocates resources for the user. Using run as in documentation is not acceptable in the multiuser environment. In clean cloud implementation, Pis is hidden in secured browser storage. Stateful. A stateful client can only assign proper access attributes. P.S. Existence of Pid may prevent double container creation but, I think, it is correct.

.......