Customize Mount Name

[joshuanianji]

Right now, mounts are uniquely identified based on the devcontainer ID (${devcontainerId}-gh-cli). The benefits are that every login is separate, so you can log into different accounts in different devcontainers.

The main drawback is that you have to re-login for every devcontainer. Customizing the mount name would allow users to specify a name like "devcontainer-gh-cli" that is shared among all devcontainers that also have the same name. This allows for greater flexibility with sharing github cli logins.

I just have to figure out if the mount values can vary based on the inputs...

[joshuanianji]

There are a few ways I can think of doing this

Method 1: mountName option (infeasible)

My first thought was to have a "mountName" option that could either be the default ${devcontainerId}-gh-cli or a custom name chosen by the user. The mounts.source option will them be defined as ${options.mountName}. I am set on using the ${devcontainerId} variable in the default as it is a unique identifier for the container and stable across rebuilds (source).

Unfortunately, the devcontainerId variable can only be used in parts of the config not used for building the image - which includes inside the devcontainer options. Thus, this method will not work.

Method 2: shared mount

I can have a second mount called "shared" or something that is shared between all containers with my extension. If the user does not specify a mount name (let's say the default is "DEFAULT_MOUNT"), we will use the mount defined by the devcontainerId (${devcontainerId}-gh-cli) inside install.sh. When the user specifies an alternate mount name, say "default", we can link the ~/.config/gh folder to a folder called "default" inside this shared mount. This is a bit more roundabout and bloated, but I think it can work considering our limitations.

The only considerations I have with this is that all containers with my extension (that uses the same Docker instance) can have access to all other Github CLI authentications. This can potentially be pretty bad as, by default, the Github CLI stores the OAuth token in plaintext. What if someone creates a malicious feature that uploads your token to a random server? All they have to do is check the volume name.

The token scopes for an authenticated Github CLI OAuth token, by default, is something like "gist, read:org, repo", maybe with "workspaces" as well. I ran gh auth status a couple times in some of my devcontainers but got different values...

I think I will look at how someone can exploit this before further looking into implementing this feature.

[joshuanianji]

Update: https://github.com/orgs/devcontainers/discussions/56 👀