Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-06-06 22:19:09 -04:00
Code Issues Projects Releases Packages Wiki Activity

Revise qvm-client command description and examples

Browse source
This commit is contained in:
pierwill 2019-08-08 18:35:57 -05:00
parent a2b6838a98
commit 724b8a32f0
1 changed files with 13 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

21
developer/services/qrexec3.md
View file

@ -16,7 +16,7 @@ redirect_from:
- /wiki/Qrexec3Implementation/ - /wiki/Qrexec3Implementation/
--- ---
# Secure communication between VMs: qrexec # # Qrexec: command execution in VMs #
(*This page is about qrexec v3. For qrexec v2, see [here](/doc/qrexec2/).*) (*This page is about qrexec v3. For qrexec v2, see [here](/doc/qrexec2/).*)
@ -30,7 +30,7 @@ By default, Qubes allows VMs initiate such communications in specific circumstan
The qrexec framework generalizes this process. The qrexec framework generalizes this process.
It allows users and developers to use and design secure inter-VM tools. It allows users and developers to use and design secure inter-VM tools.
## Qrexec basics ## ## Qrexec basics: architecture and examples ##
Qrexec is built on top of *vchan*, a Xen library providing data links between VMs. Qrexec is built on top of *vchan*, a Xen library providing data links between VMs.
During domain creation, a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM. During domain creation, a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM.
@ -42,15 +42,20 @@ Typically, the first thing that a `qrexec-client` instance does is to send a req
`qrexec-client` starts a vchan server, which `qrexec-agent` then connects to. `qrexec-client` starts a vchan server, which `qrexec-agent` then connects to.
Once this channel is established, stdin/stdout/stderr from the VMprocess is passed between `qrexec-agent` and the `qrexec-client` process. Once this channel is established, stdin/stdout/stderr from the VMprocess is passed between `qrexec-agent` and the `qrexec-client` process.
So, for example, executing in dom0: The `qrexec-client` command is used to make connections to VMs from dom0.
For example, the following command
qrexec-client -e -d someVM user:'touch hello-world.txt'
creates an empty file called `hello-world.txt` in the home folder of `someVM`.
The string before the colon specifies what user to run the command as.
The `-e` flag tells `qrexec-client` to exit immediately after sending the execution request and receiving a status code from `qrexec-agent` (whether the process creation succeeded).
With this option, no further data is passed between the domains.
By contrast, the following command demonstrates an open channel between two VMs: in this case, a remote shell.
qrexec-client -d someVM user:bash qrexec-client -d someVM user:bash
allows to work with the remote shell.
The string before the first semicolon specifies what user to run the command as.
Adding `-e` on the `qrexec-client` command line results in mere command execution (no data passing), and `qrexec-client` exits immediately after sending the execution request and receiving status code from `qrexec-agent` (whether the process creation succeeded).
There is also the `-l local_program` flag -- with it, `qrexec-client` passes stdin/stdout of the remote process to the (spawned for this purpose) `local_program`, not to its own stdin/stdout.
The `qvm-run` command is heavily based on `qrexec-client`. The `qvm-run` command is heavily based on `qrexec-client`.
It also takes care of additional activities, e.g. starting the domain if it is not up yet and starting the GUI daemon. It also takes care of additional activities, e.g. starting the domain if it is not up yet and starting the GUI daemon.
Thus, it is usually more convenient to use `qvm-run`. Thus, it is usually more convenient to use `qvm-run`.