FileSystemProvider: no way of handling permissions issues

[bpasero]

Refs: https://github.com/Microsoft/vscode/issues/48421

Setup:

• clone https://github.com/bpasero/remote-fs
• F5
• click "Refresh" in the explorer
• you should see the current working directory as a remote folder using the file system provider for scheme datei://

I can think of 2 reasons why a permission error raises:

• user needs elevated rights to change a file or folder
• a file can be readonly (e.g. Windows) and to save it you need to first remove the readonly flag

Currently there does not seem to be a way to signal a) to save as elevated user or b) to remove the readonly flag.

I am not sure how relevant this is for any other file system provider that does not have these concepts but this is something our file service can do (via the options overwriteReadonly and writeElevated).

[jrieken]

I am not sure how relevant this is for any other file system provider that does not have these concepts but this is something our file service can do

Unsure, permissions and ownership is a common concept but I don't know how VS Code handles that...

[bpasero]

@jrieken the file service can return either FILE_READ_ONLY or FILE_PERMISSION_DENIED as FileOperationResult and this will surface as a notification in the UI to ask to either overwrite (the readonly one) or save as admin for the other one. If the user agrees, either overwriteReadonly or writeElevated will be set to true the next time we update the content.

I guess we would need to have similar options for the API but I am not sure how you would even possibly implement at least the writeElevated one.

[bpasero]

I pushed https://github.com/Microsoft/vscode/commit/4cce7c0743f61e46f87425046cb656e5388f7d72 to be able to preserve the "Overwrite readonly" behavior with the new file system provider. This currently hardcodes a check for file:// scheme in a text file service that is node based. I think that is fine for now and I will need to do the same for saving elevated.

[plus-]

I've been looking the github issues and different discussions but I wasn't able to find a proper answer. As this is the closest issue to my question I though about asking here.

When implementing a FileSystemProvider (for example to a remote repository), can you set the editor as read-only based on the document/file permissions (for instance if the document is locked by another user)?

If not is there an API to set the editor as readOnly more generally, that I could make use of?

[bpasero]

@plus- this is currently not possible on a per-file basis, see https://github.com/microsoft/vscode/issues/73122 for relevant feature request.

[TrevorSayre]

Would this address the scenario mentioned here: https://github.com/microsoft/vscode-remote-release/issues/390#issuecomment-496233469

[yobyot]

I was very excited to discover SSH-Remote in vscode, thinking it could replace my (limited) vi skills. But, like the OP, I need to be able to sudo to change config files in places like /etc. The audience for this feature is admins who are not necessarily coders. For these kinds of users, who are administering production systems, the option of enabling root is a non-starter. I hope the vscode team finds a way to implement the ability to sudo remotely. That would make the system a killer remote admin environment.

[ZombieProtectionAgency]

@yobyot Until something is implemented the terminal works with SSH-Remote. So you can edit a file then save it anywhere on the server and sudo mv it in the terminal without switching windows.

[wottpal]

I came here for the exact same use case as @TrevorSayre (https://github.com/microsoft/vscode-remote-release/issues/390):

I am mainly wanting this so I can edit files in /etc/nginx

It would be so damn helpful to use Vscode to remotely do some configuration on my servers!! Currently this is only possible with Atom, unfortunately..

[rob4226]

I was so excited to use this remote development extension with vscode but now seeing I can't edit any files the require permission elevation I was very disappointed...

Failed to save 'example.com': Unable to write file (NoPermissions (FileSystemError): Error: EACCES: permission denied, open '/etc/nginx/sites-available/example.com')

There must be some way to make it work. For example, I use this workaround with WinSCP when I want to work with elevated permissions but it doesn't work with vcscode:

user_name ALL=(ALL) NOPASSWD: /usr/lib/openssh/sftp-server

Then in WinSCP there is an option for it to execute a custom command prefixed with sudo like: sudo /usr/lib/openssh/sftp-server

This allows WinSCP to automatically be able to write to any file without ever having to use any passwords while you have the file under /etc/sudoers.d with the NOPASSWD directive in place. I gladly trade security temporarily for this convenience as it's easy enough to comment out that directive when you don't need it.

How can this be done with vscode and the remote-ssh-development extension? Does it use sftp-server or something else and can you add sudo in front of whatever command vscode executes on the local machine to connect to the remote?

Thank you.

[jcvtieck]

I also need this feature to edit config files under /etc/...

[wottpal]

@bpasero Obviously there is a lot of demand regarding this issue

[PaulSearcy]

Going to chime in that I need it also for making changes to WP PHP files. Since the user and group is www-data

Wanted to give another use case for this.

[RoyTinker]

I just got the idea to use VSCode for viewing/editing Apache2 config files on our team's Jenkins server... but I ran into this issue pretty quickly.

I thought I might have a workaround by specifying sudo bash as the remote command to use and using the -t option in the ssh command line to keep the terminal shell open (hostname is redacted):

Open-ended support for any command-line option seems to be implied by the example text in the textbox ssh hello@microsoft.com -A. Sadly, it appears not -- the file permissions issue still appears when connecting this way.

[pradulmt]

Not able to edit library source in remote due to this issue, for ex: files under /usr/lib/python3/dist-packages/

[adilsaju]

Please add the feature and solve this, I was having trouble in editing files in aws instances. The user I ssh into is ec2-user but that doesn't give any perm to edit files having a high permission setting.

[thorstenhirsch]

Regarding problem (a) I don't think that the FS API is the right way to go. You probably don't want to solve this on a per-file basis, but to work on the remote machine under a different user than the one you used to login. So you want to call 'su -' or 'sudo -u apache -i' directly after ssh login. This is already possible! You can do that with a RemoteCommand in the ssh config:

Host foo
  HostName foo
  RemoteCommand sudo -u apache -i

The RemoteCommand was added to OpenSSH in 2017 and I can confirm that it works on macOS Catalina, even though vim's syntax highlighting doesn't recognize it, yet.

[ynot729]

it seems like it should be part of the ssh setup as @thorstenhirsch mentions

This is already possible! You can do that with a RemoteCommand in the ssh config:

Host foo
  HostName foo
  RemoteCommand sudo -u apache -i

It works when I try it directly in the command line but seems to be skipped when entered in the config file. @thorstenhirsch when you say it work do you mean from the command line or through the vscode connection?

[afischer-opentext-com]

Per the logs when configuring this, what reaches the ssh client is something like

[14:00:52.230] Running script with connection command: "C:\Program Files\Git\usr\bin\ssh.exe" -T -D 63356 -o RemoteCommand=none <remotehost> bash

So either there is something which actively Nulls the RemoteCommand or their needs to be some tweaking.

Update: Per https://github.com/microsoft/vscode-remote-release/issues/158 this approach is not supported unfortunately.

[thorstenhirsch]

Yes, I'm sorry, my test was flawed. It really doesn't work due to -o RemoteCommand=none, which is a hard-coded parameter in the remote-ssh extension. I removed it (in the extension's extension.js) to see what happens:

• macOS client, ArchLinux server, w/o RemoteCommand: connection works
• macOS client, ArchLinux server, RemoteCommand sudo su -: could not establish ssh connection
• Win7 client, RHEL7 server, w/o RemoteCommand: error, something like "tried to write to a non-existent channel"
• Win7 client, RHEL7 server, RemoteCommand sudo -u some_user -i: error, something like "tried to write to a non-existent channel"

Guess that's the reason why they're using -o RemoteCommand=none.

[dbogatov]

VS Code already supports "Save as admin" for local files, why not to support it in the same way for remote?

[wottpal]

VS Code already supports "Save as admin" for local files, why not to support it in the same way for remote?

Couldn’t agree more 👍👍👍

[Erwinstein]

Just found out about VSCode Remote Extensions today. After a few hours of tinkering, i tried doing sudo code /etc/nginx/nginx.conf and obviously it didn't work. Which brought me here. I hope this can be implemented in the future. VS Code would be sooo useful for admins who already use VS Code for other stuff.

[therist]

I'm also desperate about this ability. It's especially good working in VS text editor when you work with huge config files. I tried going the long route of adding my user to every group (www-data, root, etc.) that owns the config files, and giving that group also write permissions everywhere I need it. Trouble is that even after a reload the user is not part of those new groups. I have lost almost a day on this, and groups can be implemented only after you delete everything (vscode related) on the server, and reinstall again, which is a pain in the a..

[thorstenhirsch]

I did some more experimenting and I've found a way that works. -o RemoteCommand=none is not the only thing in this extension that prevents VS Code from establishing a working ssh session after calling sudo -u newuser -i, we also need to remove bash so that VS Code does not start an additional shell session on the remote host.

Here's a HOWTO:

1. make sure that sudo -u newuser -i works in a regular ssh session without requesting a password
2. remove "-o RemoteCommand=none" and "bash" from extension.js like so

   sed -i s/"-o RemoteCommand=none"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js
   sed -i s/"bash"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js

3. create an ssh config entry with a RemoteCommand like this one:

   Host pi-for-newuser
   Hostname pi
   User pi
   RemoteCommand sudo -u newuser -i

   This has been tested successfully with the following setups:

• macOS 10.15.2 with VS Code 1.41.1/remote-ssh 0.48.0 to Raspbian (stretch)
• Arch Linux with VS Code 1.38.1/remote-ssh 0.47.2 to Raspbian (stretch)

This of course is a workaround only. I hope the developers of this extension find a way to incorporate the necessary changes without breaking ssh remote connectivity for other systems.

[SassNinja]

I've ended here due to the problems already mentioned. In my case I'm trying to change files located in /etc/ what requires sudo.

@thorstenhirsch thanks for the workaround instructions!

I hope the developers of this extension find a way to incorporate the necessary changes without breaking ssh remote connectivity for other systems.

I hope the same – apparently many people need this

[adilsaju]

I did some more experimenting and I've found a way that works. -o RemoteCommand=none is not the only thing in this extension that prevents VS Code from establishing a working ssh session after calling sudo -u newuser -i, we also need to remove bash so that VS Code does not start an additional shell session on the remote host.

Here's a HOWTO:

1. make sure that sudo -u newuser -i works in a regular ssh session without requesting a password
2. remove "-o RemoteCommand=none" and "bash" from extension.js like so

sed -i s/"-o RemoteCommand=none"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js
sed -i s/"bash"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js

1. create an ssh config entry with a RemoteCommand like this one:

Host pi-for-newuser
  Hostname pi
  User pi
  RemoteCommand sudo -u newuser -i

This has been tested successfully with the following setups:

• macOS 10.15.2 with VS Code 1.41.1/remote-ssh 0.48.0 to Raspbian (stretch)
• Arch Linux with VS Code 1.38.1/remote-ssh 0.47.2 to Raspbian (stretch)

This of course is a workaround only. I hope the developers of this extension find a way to incorporate the necessary changes without breaking ssh remote connectivity for other systems.

Works like a charm. Thank you very much! @thorstenhirsch

[exKAZUu]

Thank you very much, @thorstenhirsch. The workaround is very useful. FYI: for the latest version, we should do the following sed commands instead of @thorstenhirsch's one:

sed -i -e s/"-o[^=]*RemoteCommand=none"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js
sed -i -e s/"bash"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js

[poppaskull]

Thank you for sharing @thorstenhirsch. Works perfectly. Made my day!

[mjmucha]

I did some more experimenting and I've found a way that works. -o RemoteCommand=none is not the only thing in this extension that prevents VS Code from establishing a working ssh session after calling sudo -u newuser -i, we also need to remove bash so that VS Code does not start an additional shell session on the remote host.

Here's a HOWTO:

1. make sure that `sudo -u newuser -i` works in a regular ssh session without requesting a password

2. remove  `"-o RemoteCommand=none"` and `"bash"` from `extension.js` like so

sed -i s/"-o RemoteCommand=none"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js
sed -i s/"bash"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js

1. create an ssh config entry with a RemoteCommand like this one:

Host pi-for-newuser
  Hostname pi
  User pi
  RemoteCommand sudo -u newuser -i

This has been tested successfully with the following setups:

* macOS 10.15.2 with VS Code 1.41.1/remote-ssh 0.48.0 to Raspbian (stretch)

* Arch Linux with VS Code 1.38.1/remote-ssh 0.47.2 to Raspbian (stretch)

This of course is a workaround only. I hope the developers of this extension find a way to incorporate the necessary changes without breaking ssh remote connectivity for other systems.

Nice solution but sadly not for me. For security reasons sudo should always ask for a password.

[shubhsheth]

@mjmucha You're right. This feature needs to be properly implemented.

[RoyMudie]

Another user coming up against this problem trying to edit configs in /etc/

Like @mjmucha I'm also in an environment where sudo will always ask for a password so the workaround above won't work for me :(

[swizes]

I did some more experimenting and I've found a way that works. -o RemoteCommand=none is not the only thing in this extension that prevents VS Code from establishing a working ssh session after calling sudo -u newuser -i, we also need to remove bash so that VS Code does not start an additional shell session on the remote host.

Here's a HOWTO:

1. make sure that sudo -u newuser -i works in a regular ssh session without requesting a password
2. remove "-o RemoteCommand=none" and "bash" from extension.js like so

sed -i s/"-o RemoteCommand=none"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js
sed -i s/"bash"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js

1. create an ssh config entry with a RemoteCommand like this one:

Host pi-for-newuser
  Hostname pi
  User pi
  RemoteCommand sudo -u newuser -i

This has been tested successfully with the following setups:

• macOS 10.15.2 with VS Code 1.41.1/remote-ssh 0.48.0 to Raspbian (stretch)
• Arch Linux with VS Code 1.38.1/remote-ssh 0.47.2 to Raspbian (stretch)

This of course is a workaround only. I hope the developers of this extension find a way to incorporate the necessary changes without breaking ssh remote connectivity for other systems.

I couldn't undertand the ssh host config

let's say I have 2 users on my server

1. root (obviously)
2. testuser

should my ssh host config look like this?

Host someServer
  Hostname someServer.com
  User testuser
  RemoteCommand sudo -u testuser -i

or

Host someServer
  Hostname someServer.com
  User testuser
  RemoteCommand sudo -u somedummyuser -i

or

Host someServer
  Hostname someServer.com
  User root
  RemoteCommand sudo -u testuser -i

[tiktuk]

I solved it using ProxyJump.

Host my_host
  HostName my-host.net
  User my_user

Host my_host_as_other_user
  HostName localhost
  User other_user
  ProxyJump my_host

other_user is the one I wanted to sudo with. Now I can connect to my_host_as_other_user with VS Code ☺️ .

[daemenseth]

is there a option to get this work on windows? now the workaround gives:

RemoteCommand sudo -u some_user -i: error, something like "tried to write to a non-existent channel"

[lonix1]

@tiktuk Please correct me if I'm misunderstanding, but your workaround requires the remote host to have a superuser with access to the files in question - so it's not just the proxyjump trick, one also needs to change ownership/permissions on the remote?

(If true, on most production systems that wouldn't be allowed... We still need a good sudo elevation technique via vscode.)

[tiktuk]

@tiktuk Please correct me if I'm misunderstanding, but your workaround requires the remote host to have a superuser with access to the files in question - so it's not just the proxyjump trick, one also needs to change ownership/permissions on the remote?

That is correct, yes. In my case that other user had the required permissions already but that is not necessarily true of course. A way to sudo would still be useful.

[robdejonge]

Thank you very much, @thorstenhirsch. The workaround is very useful. FYI: for the latest version, we should do the following sed commands:

sed -i -e s/"-o[^=]*RemoteCommand=none"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js
sed -i -e s/"bash"/""/ ~/.vscode/extensions/ms-vscode-remote.remote-ssh-*/out/extension.js

The commands seem to still work, thanks for that @exKAZUu, but after the most recent update of VSC this doesn't seem to be working for me anymore.

Anybody else experiencing the same? I'm running version 1.44.2.

[exKAZUu]

@robdejonge I can still confirm my commands work with VSCode 1.44.2, ms-vscode-remote.remote-ssh-0.51.0, and ms-vscode-remote.remote-ssh-edit-0.51.0 on MacOS. (If you update the extensions, you need to run my commands again.)

[robdejonge]

@robdejonge I can still confirm my commands work with VSCode 1.44.2, ms-vscode-remote.remote-ssh-0.51.0, and ms-vscode-remote.remote-ssh-edit-0.51.0 on MacOS. (If you update the extensions, you need to run my commands again.)

Thanks for confirming. Must be a local issue then. I've re-run the commands, but it still asks me for a root password when I try to log in. On any server, for that matter. I had only discovered this hack recently, I guess I'll go back to vi for the time being! :)

[webdog]

@robdejonge It's failing for me in 1.45.0. The sed commands work and successfully update the config, but vscode fails to execute a command with elevated permissions during the ssh session (Such as editing a config in /etc/nginx, which is not owned by my login user)

[webdog]

As a quick follow up to my comment, I was able to create a workaround in my development environment, by adding my login user to an ACL to my needed folders.

For example setfacl -m u:ec2-user:rwx /etc/nginx/*

This maintains ownership of the folder to it's original owner, but grants access to reading, editing, and execution of files within a supplied directory for my user.

Two thoughts:

• I wouldn't do this in a production environment, especially on sensitive configuration files
• You'll need to confirm your environment supports File-based Access Control Lists.

[mkumar118]

@robdejonge It's failing for me in 1.45.0. The sed commands work and successfully update the config, but vscode fails to execute a command with elevated permissions during the ssh session (Such as editing a config in /etc/nginx, which is not owned by my login user)

fails for me too. I'm working on Windows 10, VS Code 1.45.0

@webdog your workaround worked for me, and also taught me something new. thanks! :)

[kinjalnyc]

Quite amazed that this is not working !

[markm77]

The other obvious workaround is just to edit in the terminal with sudo vim myFile.... 😀 It's not that bad even though a VS Code editor window would be better.... Would be really nice to have right-click option "open with sudo" or suchlike....

[jjarava]

I've found a workaround that seems to be working in my use case, without having to patch the VS Code files.

The issue I run into is trying to edit files owned by root, and in my case as in many others', direct SSH to root is not allowed... so what I've done is

I've added a new entry to my ~/.ssh/config file

### Try workaround to use vscode as root
Host devbox-code
    Hostname devbox.domain.com
    AddKeysToAgent yes
    User        ubuntu
    ForwardAgent no 
    IdentityFile ~/.ssh/my-keypair-for-devbox
    RemoteCommand sudo -u root -i

And when I use devbox-code as the remote host to connect to in VS Code Remote-SSH, I get a working VS Editor with root context; I've tested and I can open, close write etc files that are owned by root fine.

I'm running Remote-SSH 0.51.0 and VS Code Version: 1.46.1

[roblabla]

As a workaround, I use sudoedit and the terminal:

export SUDO_EDITOR="code-insiders --wait"
sudoedit /etc/hostname

This will open /etc/hostname in vscode. It will only save the content when the vscode tab containing hostname is closed though (that's how sudoedit works). This should work on Linux, and I suppose MacOS too. Furthermore, it also works under Remote SSH (assuming the target has sudoedit).

[log1cb0mb]

I had been trying all of the methods suggested above (RemoteCommand or ProxyJump etc) but none worked for me but finally the most simplest solution worked (or atleast in my use case + Public key based auth). I wanted to be able to edit any file on the remote host (through VSCode) which all are pretty much root owned.

Workaround: Nothing changed on VSCode or extension side and login to remote host with normal user BUT added sudo su command under my user's bashrc on target host which did the trick and i am able to edit and save files.

Note: Obviously the terminal switches to root with this but in case you wish to work under your own/normal user in terminal then just do: sudo -u normal_user -i exit

This does not effect the elevated rights for file editing/saving.

[ponchofiesta]

A workaround I'm using sometimes is to set ACL on the files I need to change often like this:

# on remote server:
sudo setfacl -Rm u:USERNAME:rwX,d:u:USERNAME:rwX /etc/icinga2

This sets write rights via ACL to /etc/icinga2 and all child items. You may than write all files in it.

Attention: As writing than doesn't need sudo or other procedure anymore, you should use this way carefully!

[ponchofiesta]

Of cause this works. You are using user root for login, which is mostly disabled. Not a recommended solution. I assume your RemoteCommand is not needed.