mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-02-22 03:12:22 +00:00
Fix some typos & remove unhelpful acronyms in QEMU docs
This commit is contained in:
parent
690b4ad329
commit
14194f1d56
@ -147,13 +147,13 @@
|
||||
<ul><li>
|
||||
<a href="#securitydriver">Driver instances</a>
|
||||
</li><li>
|
||||
<a href="#securitydac">POSIX DAC users/groups</a>
|
||||
<a href="#securitydac">POSIX users/groups</a>
|
||||
</li><li>
|
||||
<a href="#securitycap">Linux DAC capabilities</a>
|
||||
<a href="#securitycap">Linux process capabilities</a>
|
||||
</li><li>
|
||||
<a href="#securityselinux">SELinux MAC basic confinement</a>
|
||||
<a href="#securityselinux">SELinux basic confinement</a>
|
||||
</li><li>
|
||||
<a href="#securitysvirt">SELinux MAC sVirt confinement</a>
|
||||
<a href="#securitysvirt">SELinux sVirt confinement</a>
|
||||
</li><li>
|
||||
<a href="#securityacl">Cgroups device ACLs</a>
|
||||
</li></ul>
|
||||
@ -242,11 +242,11 @@
|
||||
elevated privileges.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="securitydac" id="securitydac">POSIX DAC users/groups</a>
|
||||
<a name="securitydac" id="securitydac">POSIX users/groups</a>
|
||||
</h3>
|
||||
<p>
|
||||
In the "session" instance, the POSIX DAC model restricts QEMU virtual
|
||||
machines (and libvirtd in general) to only have access to resources
|
||||
In the "session" instance, the POSIX users/groups model restricts QEMU
|
||||
virtual machines (and libvirtd in general) to only have access to resources
|
||||
with the same user/group ID as the client application. There is no
|
||||
finer level of configuration possible for the "session" instances.
|
||||
</p>
|
||||
@ -271,7 +271,7 @@
|
||||
run as non-root, there will be greater restrictions on what
|
||||
host resources the QEMU process will be able to access. The
|
||||
libvirtd daemon will attempt to manage permissions on resources
|
||||
to minise the likelihood of unintentionale security denials,
|
||||
to minimise the likelihood of unintentional security denials,
|
||||
but the administrator / application developer must be aware of
|
||||
some of the consequences / restrictions.
|
||||
</p>
|
||||
@ -290,9 +290,9 @@
|
||||
</p>
|
||||
</li><li>
|
||||
<p>
|
||||
When attaching PCI and USB devices to a QEMU guest,
|
||||
When attaching USB and PCI devices to a QEMU guest,
|
||||
QEMU will need to access files in <code>/dev/bus/usb</code>
|
||||
and <code>/sys/bus/devices</code>. The libvirtd daemon
|
||||
and <code>/sys/bus/pci/devices</code> respectively. The libvirtd daemon
|
||||
will automatically set the ownership on specific devices
|
||||
that are assigned to a guest at start time. There should
|
||||
not be any need for administrator changes in this respect.
|
||||
@ -313,7 +313,7 @@
|
||||
<p>
|
||||
The simplest option is the latter one, of just enabling
|
||||
the 'execute/search' bit. For any directory to be used
|
||||
for storing disk images, this can be achived by running
|
||||
for storing disk images, this can be achieved by running
|
||||
the following command on the directory itself, and any
|
||||
parent directories
|
||||
</p>
|
||||
@ -328,7 +328,7 @@
|
||||
</p>
|
||||
</li></ul>
|
||||
<h3>
|
||||
<a name="securitycap" id="securitycap">Linux DAC capabilities</a>
|
||||
<a name="securitycap" id="securitycap">Linux process capabilities</a>
|
||||
</h3>
|
||||
<p>
|
||||
The libvirt QEMU driver has a build time option allowing it to use
|
||||
@ -363,7 +363,7 @@
|
||||
to changing the <code>/etc/libvirt/qemu.conf</code> settings.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="securityselinux" id="securityselinux">SELinux MAC basic confinement</a>
|
||||
<a name="securityselinux" id="securityselinux">SELinux basic confinement</a>
|
||||
</h3>
|
||||
<p>
|
||||
The basic SELinux protection for QEMU virtual machines is intended to
|
||||
@ -393,7 +393,7 @@
|
||||
SELinux boolean.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="securitysvirt" id="securitysvirt">SELinux MAC sVirt confinement</a>
|
||||
<a name="securitysvirt" id="securitysvirt">SELinux sVirt confinement</a>
|
||||
</h3>
|
||||
<p>
|
||||
The SELinux sVirt protection for QEMU virtual machines builds to the
|
||||
@ -429,7 +429,7 @@
|
||||
labelled to match, libvirtd will not attempt any relabelling.
|
||||
</p>
|
||||
<p>
|
||||
If the sVirt security model is active, then the node capabilties
|
||||
If the sVirt security model is active, then the node capabilities
|
||||
XML will include its details. If a virtual machine is currently
|
||||
protected by the security model, then the guest XML will include
|
||||
its assigned labels. If enabled at compile time, the sVirt security
|
||||
|
@ -85,11 +85,11 @@
|
||||
elevated privileges.
|
||||
</p>
|
||||
|
||||
<h3><a name="securitydac">POSIX DAC users/groups</a></h3>
|
||||
<h3><a name="securitydac">POSIX users/groups</a></h3>
|
||||
|
||||
<p>
|
||||
In the "session" instance, the POSIX DAC model restricts QEMU virtual
|
||||
machines (and libvirtd in general) to only have access to resources
|
||||
In the "session" instance, the POSIX users/groups model restricts QEMU
|
||||
virtual machines (and libvirtd in general) to only have access to resources
|
||||
with the same user/group ID as the client application. There is no
|
||||
finer level of configuration possible for the "session" instances.
|
||||
</p>
|
||||
@ -116,7 +116,7 @@
|
||||
run as non-root, there will be greater restrictions on what
|
||||
host resources the QEMU process will be able to access. The
|
||||
libvirtd daemon will attempt to manage permissions on resources
|
||||
to minise the likelihood of unintentionale security denials,
|
||||
to minimise the likelihood of unintentional security denials,
|
||||
but the administrator / application developer must be aware of
|
||||
some of the consequences / restrictions.
|
||||
</p>
|
||||
@ -138,9 +138,9 @@
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
When attaching PCI and USB devices to a QEMU guest,
|
||||
When attaching USB and PCI devices to a QEMU guest,
|
||||
QEMU will need to access files in <code>/dev/bus/usb</code>
|
||||
and <code>/sys/bus/devices</code>. The libvirtd daemon
|
||||
and <code>/sys/bus/pci/devices</code> respectively. The libvirtd daemon
|
||||
will automatically set the ownership on specific devices
|
||||
that are assigned to a guest at start time. There should
|
||||
not be any need for administrator changes in this respect.
|
||||
@ -162,7 +162,7 @@
|
||||
<p>
|
||||
The simplest option is the latter one, of just enabling
|
||||
the 'execute/search' bit. For any directory to be used
|
||||
for storing disk images, this can be achived by running
|
||||
for storing disk images, this can be achieved by running
|
||||
the following command on the directory itself, and any
|
||||
parent directories
|
||||
</p>
|
||||
@ -178,7 +178,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3><a name="securitycap">Linux DAC capabilities</a></h3>
|
||||
<h3><a name="securitycap">Linux process capabilities</a></h3>
|
||||
|
||||
<p>
|
||||
The libvirt QEMU driver has a build time option allowing it to use
|
||||
@ -215,7 +215,7 @@
|
||||
to changing the <code>/etc/libvirt/qemu.conf</code> settings.
|
||||
</p>
|
||||
|
||||
<h3><a name="securityselinux">SELinux MAC basic confinement</a></h3>
|
||||
<h3><a name="securityselinux">SELinux basic confinement</a></h3>
|
||||
|
||||
<p>
|
||||
The basic SELinux protection for QEMU virtual machines is intended to
|
||||
@ -246,7 +246,7 @@
|
||||
SELinux boolean.
|
||||
</p>
|
||||
|
||||
<h3><a name="securitysvirt">SELinux MAC sVirt confinement</a></h3>
|
||||
<h3><a name="securitysvirt">SELinux sVirt confinement</a></h3>
|
||||
|
||||
<p>
|
||||
The SELinux sVirt protection for QEMU virtual machines builds to the
|
||||
@ -286,7 +286,7 @@
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If the sVirt security model is active, then the node capabilties
|
||||
If the sVirt security model is active, then the node capabilities
|
||||
XML will include its details. If a virtual machine is currently
|
||||
protected by the security model, then the guest XML will include
|
||||
its assigned labels. If enabled at compile time, the sVirt security
|
||||
|
Loading…
x
Reference in New Issue
Block a user