[Feature Request] Adding access/function control policies to vscode-server

[einsitang]

When deploying vscode-server, I want to provide different permissions and functionality restrictions for each instance:

• Workspace file read and write permissions
• Terminal environment control authority
• VS Code configuration (lock the settings.json file)

Usage scenario

When using VSCode Web, I can restrict the functions for different users to prevent them from intentionally or unintentionally damaging the instance environment or consuming excessive resources.

If I am conducting a project demonstration or giving a simple engineering explanation, I would like the users to be able to directly open VSCode via the web, but only in the capacity of a visitor to view the files, without the ability to modify or execute any functions.

I have tried many solutions, such as modifying the settings.json file and restricting the write permissions for this file.But this is merely to impose some UI-level functional restrictions on VSCode.

I can use containers to isolate instances to prevent them from affecting other user environments. However, this consumes resources and still cannot effectively prevent malicious damage.

Users can bypass this by modifying the settings.json file in the workspace. Once users can access the system files through the terminal, they can do so.
I think it is necessary to impose restrictions at the extension host level to achieve the above functionality.

If they are core members of the team, I can allocate sufficient performance Docker container instances based on their capability assessment to isolate the environment conflicts among them. However, if it is opened to other visitor-level users, it is impossible to provide a container instance for each user, which would be very costly. It is hoped to provide them with a shared read-only instance and prohibit them from using terminals or other resources that may damage the environment or consume high-load resources.

[aeschli]

I would like the users to be able to directly open VSCode via the web, but only in the capacity of a visitor to view the files, without the ability to modify or execute any functions.

It sounds like this needs to done by the OS, through access rights?

[einsitang]

I would like the users to be able to directly open VSCode via the web, but only in the capacity of a visitor to view the files, without the ability to modify or execute any functions.

It sounds like this needs to done by the OS, through access rights?

My idea is to impose restrictions on VSCode and the extension host, and to allow or block read and write operations.

This feature is mainly applicable to the web version. It enables administrators to restrict the functions of the current instance for different accessing users. This user does not necessarily have to be a Linux user.

• For instance, for some hosts (containers) that are under high-risk or have high-performance loads, their execution can be prevented, and only users with high privileges will be allowed to execute.

• For instance, some projects are only for viewing in the editor and do not allow for modification or running.but language server plugin can be run and is used to assist with formatting and the syntax checking of the current project.

This way, multiple users can use the same instance of vscode-server, eliminating the need to have each user run their own instance separately.

Because they cannot modify the content of the workspace, there is no conflict.

[aeschli]

The code server was not designed for this. It is assumed that a code server is per user. The extensions in the extension host are node applications and have full access to the file system and can run any process with the users privileges.

[einsitang]

The code server was not designed for this. It is assumed that a code server is per user. The extensions in the extension host are node applications and have full access to the file system and can run any process with the users privileges.

Yes, I understand that this is the current design, which is very reasonable for a complete VS application. I just hope that an ACL strategy can be added so that some scenarios (teaching, code review/demonstration) can be deployed and used at a lower server resource cost.

[vs-code-engineering]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!