> >> So now the .nix file for appvm has two sections, one that is executed as
> >> root and one as user.
> >> Here is the sample of this definitions:
> >>
> >> { config ? import ../../../nix/eval-config.nix {} }:
> >>
> >> import ../make-vm.nix { inherit config; } {
> >>  providers.net = [ "netvm" ];
> >>
> >>  run = config.pkgs.pkgsStatic.callPackage (
> >>   { writeScript }:
> >>    writeScript "run-root-shell" ''
> >>      #!/bin/execlineb -P
> >>      /bin/sh
> >>    ''
> >>  ) { };
> >>
> >>  run-as-user = config.pkgs.pkgsStatic.callPackage (
> >>    { writeScript, lynx }:
> >>    writeScript "run-lynx" ''
> >>      #!/bin/execlineb -P
> >>      ${lynx}/bin/lynx https://www.google.com/url?q=https://spectrum-os.org&source=gmail-imap&ust=1670931764000000&usg=AOvVaw3fPCahT573bNMQKMWAGTEW
> >>    ''
> >>  ) { };
> >>
> >> }
> >
> > I'm not too sure about this part — it seems like quite a lot of
> > complexity in the app VM implementation, when dropping privileges
> > (unless there's something I haven't considered?) should be as simple as
> > putting "s6-applyuidgid -u 1000 -g 1000" in the VM run script at the
> > point where privileges can be dropped.
>
> I think it’s more flexibility rather than complexity.
> Also because of immature nature of the Spectrum OS it is good to have some extra tools for developers to debug the stuff and to have extra controls.
> I can think of refactoring	this on the /img/vm level — I’m using su and not s6-tools,  if you’re interested in this patchset in general.

Would you mind explaining what makes run-as-user more flexible?
As far as I can tell, run-as-user doesn't make it possible to do
anything that wasn't possible before.

> >> Cloud-hypervisor has virtual hardware limitations -- it supports only one
> >> console device and only one serial device.
> >> SpectrumOS is using serial device for kernel logs of appVM and console
> >> device as a console.
> >> To have access both to root-executed part and to user-executed part of the
> >> VM payload, I installed a tmux on console.
> >> Now, when you're running vm-console command  you get access to the tmux
> >> and have the ability to switch between root and user consoles,
> >> that can be useful during debugging VM payload.
> >>
> >> To run Firefox appVM use vm-start-way command: vm-start-way appvm-firefox :)
> >
> > Would it work with virtio-gpu?  I'm still not convinced on Waypipe —
> > where the previous discussion left off, we were talking about VMs over
> > the network.  That would be an interesting thing to look at (and it
> > would be really cool if we could make it work!), but doing it would take
> > a lot more than just network-transparent Wayland proxying, so if that's
> > the main thing we'd get out of Waypipe, I think it would only make sense
> > to add Waypipe support as part of that bigger work.  (And this point in
> > time, when how VMs work at all in Spectrum is a bit in flux, is probably
> > not the best time to start trying to massively expand their scope!)
>
> I think it’s the wrong question	:-)
> Both implementations of wayland passthru ( virtio-gpu and waypipe) are ugly right now but they both allow to move the development forward. But someday I believe they’ll become nice. I really believe! :-)
>
> The thing is definitely needed in the mainline is abstraction layer for wayland apps — to move all proxying and other system or hardware dependant details out of VM’s descriptions — we define that is an wayland appVM ( like it’s defined it’s networking appVM) and the mechanisms of how the WAYLAND_DISPLAY gets to the is covered by this abstraction layer.

Agreed on that.  I want to get to the place soon where we can run
arbitrary applications on Spectrum, without having to create custom VM
definitions for each one.  To be able to do that, we'll need the
environment an application it runs in to be set up as common
applications expect.  So WAYLAND_DISPLAY, etc. will need to be set up.
And then if you want to use Waypipe instead of virtio-gpu, you just need
to make a custom template that does that.