Fix over indented code blocks

This commit is contained in:
Marek Marczykowski-Górecki 2021-03-28 20:58:39 +02:00
parent 0824b2d196
commit 752f1d4ddc
No known key found for this signature in database
GPG key ID: F32894BE9684938A
16 changed files with 530 additions and 492 deletions

View file

@ -23,13 +23,13 @@ Before passing user input, the socket service will receive a null-terminated ser
When running in a VM, this is:
```
<service_name> <source>\0
<service_name> <source>\0
```
When running in dom0, it is:
```
<service_name> <source> <target_type> <target>\0
<service_name> <source> <target_type> <target>\0
```
(The target type can be `name`, in which case target is a domain name, or `keyword`, in which the target is a keyword like `@dispvm`).

View file

@ -33,7 +33,7 @@ the stdin/stdout/stderr from this remote process will be passed to the
E.g., to start a primitive shell in a VM type the following in Dom0 console:
```shell_session
[user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d <vm name> user:bash
[user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d <vm name> user:bash
```
The string before first semicolon specifies what user to run the command as.
@ -102,21 +102,21 @@ whose names describe the available RPC actions; their content is the RPC
access policy database. Some example of the default services in Qubes are:
```
qubes.Filecopy
qubes.OpenInVM
qubes.ReceiveUpdates
qubes.SyncAppMenus
qubes.VMShell
qubes.ClipboardPaste
qubes.Gpg
qubes.NotifyUpdates
qubes.PdfConvert
qubes.Filecopy
qubes.OpenInVM
qubes.ReceiveUpdates
qubes.SyncAppMenus
qubes.VMShell
qubes.ClipboardPaste
qubes.Gpg
qubes.NotifyUpdates
qubes.PdfConvert
```
These files contain lines with the following format:
```
srcvm destvm (allow|deny|ask)[,user=user_to_run_as][,target=VM_to_redirect_to]
srcvm destvm (allow|deny|ask)[,user=user_to_run_as][,target=VM_to_redirect_to]
```
You can specify `srcvm` and `destvm` by name, or by one of `$anyvm`,
@ -142,7 +142,7 @@ name of the program that will be invoked.
In a src VM, one should invoke the qrexec client via the following command:
```
/usr/lib/qubes/qrexec-client-vm <target vm name> <service name> <local program path> [local program arguments]
/usr/lib/qubes/qrexec-client-vm <target vm name> <service name> <local program path> [local program arguments]
```
Note that only stdin/stdout is passed between RPC server and client --
@ -176,7 +176,7 @@ In order to remove such authorization, issue this command from a Dom0 terminal
(example below for `qubes.Filecopy` service):
```shell_session
sudo nano /etc/qubes-rpc/policy/qubes.Filecopy
sudo nano /etc/qubes-rpc/policy/qubes.Filecopy
```
and then remove any line(s) ending in "allow" (before the first `##` comment)
@ -193,37 +193,37 @@ integers on the target VM and returns back the result to the invoking VM.
* Client code on source VM (`/usr/bin/our_test_add_client`)
```bash
#!/bin/sh
echo $1 $2 # pass data to rpc server
exec cat >&$SAVED_FD_1 # print result to the original stdout, not to the other rpc endpoint
```
```bash
#!/bin/sh
echo $1 $2 # pass data to rpc server
exec cat >&$SAVED_FD_1 # print result to the original stdout, not to the other rpc endpoint
```
* Server code on target VM (`/usr/bin/our_test_add_server`)
```bash
#!/bin/sh
read arg1 arg2 # read from stdin, which is received from the rpc client
echo $(($arg1+$arg2)) # print to stdout - so, pass to the rpc client
```
```bash
#!/bin/sh
read arg1 arg2 # read from stdin, which is received from the rpc client
echo $(($arg1+$arg2)) # print to stdout - so, pass to the rpc client
```
* Policy file in dom0 (`/etc/qubes-rpc/policy/test.Add`)
```shell_session
$anyvm $anyvm ask
```
```shell_session
$anyvm $anyvm ask
```
* Server path definition on target VM (`/etc/qubes-rpc/test.Add`)
```
/usr/bin/our_test_add_server
```
```
/usr/bin/our_test_add_server
```
* To test this service, run the following in the source VM:
```
/usr/lib/qubes/qrexec-client-vm <target VM> test.Add /usr/bin/our_test_add_client 1 2
```
```
/usr/lib/qubes/qrexec-client-vm <target VM> test.Add /usr/bin/our_test_add_client 1 2
```
and we should get "3" as answer, provided dom0 policy allows the call to pass
through, which would happen after we click "Yes" in the popup that should