On Sun, Feb 4, 2018 at 5:16 AM, Andrew Clausen
<andrew.p.clau...@gmail.com> wrote:
> On 3 February 2018 at 17:09, Raffaele Florio <raffaeleflo...@protonmail.com>
>> 4) This option adds a lot of complexity and "DispVM" automatically become
>> a sort of "SessionVM". Furthermore this option increase, greatly, the
>> complexity and there is the need to communicate with Dom0. It only knows
>> about which VM is alive.
>
>
> I agree, but I do think it's worthwhile. It might need some minor changes
> to Qubes infrastructure. For instance, qvm-run --dispvm could be amended to
> return the name of the new VM on stderr, which could be re-used down the
> track.
>
>> 4.1) Nonetheless I can add an option (in quick settings) to define a
>> handler VM associated with the current tab. However you can already open in
>> specific VM (also DispVM,) a link, through context menu entries. I don't
>> consider this a vital and very useful feature. I consider the currently
>> granularity, sufficient. However I'll wait for other opinions and Qubes 4.0,
>> because in the old post [0] I was warned about substantial change regarding
>> the privilege that permits a VM to choose which VM should handle an action.
>
>
> I do think it's valuable to make these easy (i.e. few clicks, and few
> choices during the normal course of things). And I do think VM re-use is
> important, since VMs use so much resources. Qubes 4.0 adds a new
> confirmation window by default, but the user can control its behaviour with
> Qubes RPC policy rules.
>
> One possible solution would be to add a new type of Qubes RPC rule: present
> the user with the most recently opened DispVM to use as a default (that they
> can change before clicking OK). It might look something like this:
>
> /etc/qubes-rpc/policy/qubes.OpenURL:
>
> $anyvm $dispvm ask,reuse
>
> (I think this idea needs a bit more thought!)
As to point 4 and the implementation of VM re-use, nothing additional
is necessary from the current qubes-rpc plumbing.
Returning a name would be undesirable since the source VM should not
be able to specify a specific destination VM (indeed, ideally might
not even know the names of any other VMs on the system). Increasing
complexity of the policy evaluation logic is also undesirable, since
this should ideally be kept as simple as possible.
A solution today might include a service like:
$ cat url-redirector.RemoteOpenSession
#!/bin/sh
while read -r url; do
case "$url" in
http://*|\
https://*|\
ftp://*)
qubes-open "$url"
;;
*)
echo "Invalid URL" >&2
;;
esac
done
and be invoked from another VM with:
$ qrexec-client-vm '' url-redirector.RemoteOpenSession
This allows the source VM to keep a handle to an anonymous destination
VM to open arbitrary links in the future, without any cooperation or
changes in dom0 or policy evaluation or anything.
Regards,
Jean-Philippe
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/CABQWM_BLL-o%3DReW0a8vb1jDNRS7vj%2BMaeQiLXWz%2BMwJa%2BeUVXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
