search

flathub / com.visualstudio.code.oss

https://flathub.org/apps/details/com.visualstudio.code.oss
GNU Affero General Public License v3.0
47 stars 12 forks source link

Give the embedded terminal access to host system #5

Closed thiblahute closed 5 years ago

thiblahute commented 6 years ago

For the terminal to be really useful it should be able to use host access (through the HostCommand mechanism in flatpak). This requires upstream work but I report here as I guess it is the place where I might actually have an answer about the problem).

TingPing commented 6 years ago

That is very much not trivial work and would require upstream to genuinely care about the sandbox'd use-case in general.

thiblahute commented 6 years ago

That is very much not trivial work and would require upstream to genuinely care about the sandbox'd use-case in general.

True, but without that this flatpak is mostly useless to me :-)

amtlib-dot-dll commented 6 years ago

Sounds nice, but this might not be a priority for me. 😀 If you have a patch you can submit it here or directly to the upstream @thiblahute

juhp commented 6 years ago

Actually not just the terminal, various extensions also need to run host system tools.

mzabaluev commented 6 years ago

I think this and other tool running scenarios could be enabled by the following:

  1. A D-Bus service that would (with some user-controlled whitelisting) run host binaries attached to caller-provided file descriptors for stdin/stdout/stderr, and provide lifecycle controls and signal proxying.
  2. A "tool proxy" executable inside the container, which uses the D-Bus service to run the actual tool and serves as its container-side stand-in with regard to signals and exit status.

That's a complicated way to solve the issue, but I don't know any means for a child process to migrate from the container's namespaces out to the host.

amtlib-dot-dll commented 6 years ago

@mzabaluev You may just run bwrap directly and don't unshare the PID namespace https://github.com/projectatomic/bubblewrap/blob/master/bwrap.xml#L110

mzabaluev commented 6 years ago

@amtlib-dot-dll Is it possible to use bwrap inside the sandbox to get out of it? The binary is not currently available in the sandbox. Most tools also need access to the host filesystem.

mzabaluev commented 6 years ago

I've done some reading up, which should have been a prerequisite... So 1. above could be provided by HostCommand API or its suitably "portalized" derivative. What about 2? Is it feasible to provide a generic tool wrapper that would use the Flatpak D-Bus service to run processes on the host, so that Visual Studio Code and other IDEs would not need modifications for running in a sandbox? Note that the embedded terminal widget itself does not need to run on the host.

amtlib-dot-dll commented 6 years ago

No, I meant that

More info here and here

Personally I use Flatpak for isolation and I don't think that interacting with the outside world is a good idea. Why not use the non-Flatpaked version if you don't need isolation?

mzabaluev commented 6 years ago

@amtlib-dot-dll I see. I'd like a solution that would work out of the box in Flatpak without giving the app the keys to the whole kingdom.

amtlib-dot-dll commented 6 years ago

@mzabaluev Anyway, if you want something work out of the box, it should be insecure. It is hard to have both security and convenience.

TingPing commented 6 years ago

An IDE is one tool where you simply have to forego security for usablity. See GNOME-Builder on how to handle this.

amtlib-dot-dll commented 6 years ago

I'd like a solution that would work out of the box in Flatpak without giving the app the keys to the whole kingdom.

An IDE is one tool where you simply have to forego security for usablity.

:woman_shrugging: Personally this is not essential to me so I added "help wanted" tag looking for someone else to deal with this

TingPing commented 6 years ago

Yea it is certainly impossible to be sandboxed and not be sandboxed at the same time as they request. But as mentioned this requires deep redesign in the project, this isn't a toggle somebody can just make.

mzabaluev commented 6 years ago

I'm thinking of a possible future where Flatpak is the way to distribute desktop applications. That future needs to have a solution for IDEs, terminal emulators, and the like.

The requirements on host filesystem access differ between the "tool runner" application itself and the tools the user may want to run from it. The former needs the sandbox runtime /usr to work, but the user-specified tools, shells, etc. are often expected to run outside the app container's namespace (at least until it's containers all the way down and the user doesn't ever need to access the host system).

amtlib-dot-dll commented 6 years ago

Hmmm, can you add an option to share the PID namespace with the host in Flatpak? That is, remove the --unshare-pid of bwrap @TingPing @alexlarsson :thinking:

TingPing commented 6 years ago

@mzabaluev Again this is possible today, see GNOME-Builder, the tool just has to do it...

G-Ray commented 5 years ago

Any update on this ? I switched back to the proprietary vscode binary because some extensions need to access the host.

Ben-Voris commented 5 years ago

This affects more than the pid namespace. It prevents access to header files and alternative tools that aren't part of the project but aren't in the permission list. For example, this compiler exists:

: file /usr/bin/x86_64-w64-mingw32-gcc-win32
/usr/bin/x86_64-w64-mingw32-gcc-win32: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=d1e1d2111a6d2cdb3f872748463056e1c21cfcce, stripped

But the shell prompt in Visual Studio - OSS gives:

$ file /usr/bin/x86_64-w64-mingw32-gcc-win32
/usr/bin/x86_64-w64-mingw32-gcc-win32: cannot open `/usr/bin/x86_64-w64-mingw32-gcc-win32' (No such file or directory)

Some include files end up at unexpected locations, like the following. Again, the first output is from a terminal session and the second from the

$ find / -name winsock2.h -ls 2> /dev/null
  4466632      0 lrwxrwxrwx   1  nfsnobody nfsnobody       40 Nov 18  2017 /run/host/usr/i686-w64-mingw32/include/winsock2.h -> ../../share/mingw-w64/include/winsock2.h
  4464715     52 -rw-r--r--   1  nfsnobody nfsnobody    49590 Nov 18  2017 /run/host/usr/share/mingw-w64/include/winsock2.h
  4472138      0 lrwxrwxrwx   1  nfsnobody nfsnobody       40 Nov 18  2017 /run/host/usr/x86_64-w64-mingw32/include/winsock2.h -> ../../share/mingw-w64/include/winsock2.h

: find / -name winsock2.h -ls 2> /dev/null
  4466632      0 lrwxrwxrwx   1 root     root           40 Nov 18  2017 /usr/i686-w64-mingw32/include/winsock2.h -> ../../share/mingw-w64/include/winsock2.h
  4464715     52 -rw-r--r--   1 root     root        49590 Nov 18  2017 /usr/share/mingw-w64/include/winsock2.h
  4472138      0 lrwxrwxrwx   1 root     root           40 Nov 18  2017 /usr/x86_64-w64-mingw32/include/winsock2.h -> ../../share/mingw-w64/include/winsock2.h

$ find / -name winsock2.h -ls 2> /dev/null
  4466632      0 lrwxrwxrwx   1  nfsnobody nfsnobody       40 Nov 18  2017 /run/host/usr/i686-w64-mingw32/include/winsock2.h -> ../../share/mingw-w64/include/winsock2.h
  4464715     52 -rw-r--r--   1  nfsnobody nfsnobody    49590 Nov 18  2017 /run/host/usr/share/mingw-w64/include/winsock2.h
  4472138      0 lrwxrwxrwx   1  nfsnobody nfsnobody       40 Nov 18  2017 /run/host/usr/x86_64-w64-mingw32/include/winsock2.h -> ../../share/mingw-w64/include/winsock2.h
TingPing commented 5 years ago

Honestly I'm just going to close this as there seems to be a misunderstanding:

In order to run host binaries you must go through an abstraction like flatpak-spawn --host some-tool.

In order for the terminal to run on the host by default it requires contributing to vscode directly. This is not a package issue and cannot be resolved here.