ihucos

gVisor is primarly focused on isolation, plash actually only wants to containerize processes and leaves optional isolation to other tools if required (potentially gVisor).

To quote gVisor:

  Containers are not a sandbox. While containers have revolutionized how we develop, package, and deploy applications, running untrusted or potentially malicious code without additional isolation is not a good idea.

I think the approach gVisor uses is basically the same that is used to run python on Googles web hosting platform. As I understand it, with gVisor a process does not directly talk to the kernel but actually to another process.

> This is going to be a great world when we have arbitrary nesting of containers, finally we will have closure :)

Yep. With plash you can do that (In plash unprivileged containers inside unprivileged containers also works, but may need some looking into it).

> I think "docker compose" is a big lie.

I also have strong feelings about docker compose. It's really reinventing everything but now for containers. With plash you can just use supervisord, the init of your operating system and other established means of managing background processes.

Hey,

Yeah, that should work. It usually uses linux namespaces/overlay/unionfs/mount/chroot there are no dependencies on hyper-V.

In the worst case scenario plash would also be happy with not cleaning up mountpoints (PLASH_NO_UNSHARE=1) and using unionfs-fuse. During development I run it on FreeBSD and macOS. So its quite portable. Feel free to send me an mail (mail at irae me) for support.

EDIT: Running it natively on a non Linux-System is probably not what you think, since you can't run a linux root file system for example on top of the macOS kernel. Experimenting with the FreeBSD linux abi emulation layer did not yield usable results for me.

Yep true. I am still trying to figure out how to write good documentation/tutorials. I will definitely write some general recipes in the README for common tasks, some also doable in other container software like mounting containers, importing from docker, exporting to docker, using an image published in github etc. I'll shortly ping you via PM afterwards.

I think the simplest would be like this:

  ihucos@macbook:~$ docker run --privileged --volume /var/lib/plash -ti python bash
  root@d2a59ae96bc2:/# pip3 install plash
  Collecting plash
    Downloading https://files.pythonhosted.org/packages/41/9a/a3a7c6fd104ff197b7656a51e1b396eee42bde3a578d70eb1c5d524e8e0f/plash-1.1359-py3-none-any.whl (749kB)
    100% || 757kB 2.0MB/s 
  Installing collected packages: plash
  Successfully installed plash-1.1359
  root@d2a59ae96bc2:/# plash init
  root@d2a59ae96bc2:/# plash -A
  plash: fetching 100%
  plash: extracting...
  d2a59ae96bc2:/# type apk
  apk is /sbin/apk
  d2a59ae96bc2:/# printf hello from alpine
  hellod2a59ae96bc2:/# root@d2a59ae96bc2:/# exit
  exit

ohh yeah, you would need to save to builded container somewhere or pipe it out from docker (but docker does not differentiate stderr and stdout). In any case to import the container builded with plash back to the docker:

  ihucos@macbook:~$ plash export-tar --eval-file /tmp/plashscript | docker import -
  + touch /hello
  --:
  sha256:8e26d9d222bb4840feb3aeb475522e76aa8fa835049eac08121961694203e99e

Good morning,

it certainly would be very nice. I explored this a little bit but on the end had to focus on stability of the core components. It wouldn't be anything too hard, but quite a lot of work to implement all the syntax quirks, keeping up with new commands, etc. So right now at least I personally don't have concrete plans to implement it. What you can do right now is use images from a local docker installation:

$ plash --from-docker busybox -- printf hi

Blockchain only solves one part of the problem. All end devices are not secure. My mother keeps clicking on funny ads and single hardware components may be compromised.

I appreciate your feedback too and agree that security related code is a sensitive thing. I did not loose any thought on the actual hashing and as written in the readme this is just a prototype. The key aspect of Passpod and on what I'd love to get some feedback is the idea to save the passwords in a giant set of hashes instead of the commonly used map of clear usernames and hashed passwords. I wrongfully supposed that it would be obvious that the actual hashing is just meant to be a placeholder. So I changed sha512 to md5 and documented that the actual hashing is broken accordingly.