+#: ../src/guestfs.pod:931
+msgid ""
+"We guarantee the libguestfs ABI (binary interface), for public, high-level "
+"actions as outlined in this section. Although we will deprecate some "
+"actions, for example if they get replaced by newer calls, we will keep the "
+"old actions forever. This allows you the developer to program in confidence "
+"against the libguestfs API."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:937
+msgid "BLOCK DEVICE NAMING"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:939
+msgid ""
+"In the kernel there is now quite a profusion of schemata for naming block "
+"devices (in this context, by I<block device> I mean a physical or virtual "
+"hard drive). The original Linux IDE driver used names starting with "
+"C</dev/hd*>. SCSI devices have historically used a different naming scheme, "
+"C</dev/sd*>. When the Linux kernel I<libata> driver became a popular "
+"replacement for the old IDE driver (particularly for SATA devices) those "
+"devices also used the C</dev/sd*> scheme. Additionally we now have virtual "
+"machines with paravirtualized drivers. This has created several different "
+"naming systems, such as C</dev/vd*> for virtio disks and C</dev/xvd*> for "
+"Xen PV disks."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:951
+msgid ""
+"As discussed above, libguestfs uses a qemu appliance running an embedded "
+"Linux kernel to access block devices. We can run a variety of appliances "
+"based on a variety of Linux kernels."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:955
+msgid ""
+"This causes a problem for libguestfs because many API calls use device or "
+"partition names. Working scripts and the recipe (example) scripts that we "
+"make available over the internet could fail if the naming scheme changes."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:960
+msgid ""
+"Therefore libguestfs defines C</dev/sd*> as the I<standard naming scheme>. "
+"Internally C</dev/sd*> names are translated, if necessary, to other names as "
+"required. For example, under RHEL 5 which uses the C</dev/hd*> scheme, any "
+"device parameter C</dev/sda2> is translated to C</dev/hda2> transparently."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:966
+msgid ""
+"Note that this I<only> applies to parameters. The L</guestfs_list_devices>, "
+"L</guestfs_list_partitions> and similar calls return the true names of the "
+"devices and partitions as known to the appliance."
+msgstr ""
+
+# type: =head3
+#: ../src/guestfs.pod:971
+msgid "ALGORITHM FOR BLOCK DEVICE NAME TRANSLATION"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:973
+msgid ""
+"Usually this translation is transparent. However in some (very rare) cases "
+"you may need to know the exact algorithm. Such cases include where you use "
+"L</guestfs_config> to add a mixture of virtio and IDE devices to the "
+"qemu-based appliance, so have a mixture of C</dev/sd*> and C</dev/vd*> "
+"devices."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:979
+msgid ""
+"The algorithm is applied only to I<parameters> which are known to be either "
+"device or partition names. Return values from functions such as "
+"L</guestfs_list_devices> are never changed."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:987
+msgid "Is the string a parameter which is a device or partition name?"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:991
+msgid "Does the string begin with C</dev/sd>?"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:995
+msgid ""
+"Does the named device exist? If so, we use that device. However if I<not> "
+"then we continue with this algorithm."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1000
+msgid "Replace initial C</dev/sd> string with C</dev/hd>."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1002
+msgid "For example, change C</dev/sda2> to C</dev/hda2>."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1004
+msgid "If that named device exists, use it. If not, continue."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1008
+msgid "Replace initial C</dev/sd> string with C</dev/vd>."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1010
+msgid "If that named device exists, use it. If not, return an error."
+msgstr ""
+
+# type: =head3
+#: ../src/guestfs.pod:1014
+msgid "PORTABILITY CONCERNS WITH BLOCK DEVICE NAMING"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1016
+msgid ""
+"Although the standard naming scheme and automatic translation is useful for "
+"simple programs and guestfish scripts, for larger programs it is best not to "
+"rely on this mechanism."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1020
+msgid ""
+"Where possible for maximum future portability programs using libguestfs "
+"should use these future-proof techniques:"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1027
+msgid ""
+"Use L</guestfs_list_devices> or L</guestfs_list_partitions> to list actual "
+"device names, and then use those names directly."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1030
+msgid "Since those device names exist by definition, they will never be translated."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1035
+msgid ""
+"Use higher level ways to identify filesystems, such as LVM names, UUIDs and "
+"filesystem labels."
+msgstr ""
+
+# type: =head1
+#: ../src/guestfs.pod:1040
+msgid "SECURITY"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1042
+msgid ""
+"This section discusses security implications of using libguestfs, "
+"particularly with untrusted or malicious guests or disk images."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1045
+msgid "GENERAL SECURITY CONSIDERATIONS"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1047
+msgid ""
+"Be careful with any files or data that you download from a guest (by "
+"\"download\" we mean not just the L</guestfs_download> command but any "
+"command that reads files, filenames, directories or anything else from a "
+"disk image). An attacker could manipulate the data to fool your program "
+"into doing the wrong thing. Consider cases such as:"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1057
+msgid "the data (file etc) not being present"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1061
+msgid "being present but empty"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1065
+msgid "being much larger than normal"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1069
+msgid "containing arbitrary 8 bit data"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1073
+msgid "being in an unexpected character encoding"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1077
+msgid "containing homoglyphs."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1081
+msgid "SECURITY OF MOUNTING FILESYSTEMS"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1083
+msgid ""
+"When you mount a filesystem under Linux, mistakes in the kernel filesystem "
+"(VFS) module can sometimes be escalated into exploits by deliberately "
+"creating a malicious, malformed filesystem. These exploits are very severe "
+"for two reasons. Firstly there are very many filesystem drivers in the "
+"kernel, and many of them are infrequently used and not much developer "
+"attention has been paid to the code. Linux userspace helps potential "
+"crackers by detecting the filesystem type and automatically choosing the "
+"right VFS driver, even if that filesystem type is obscure or unexpected for "
+"the administrator. Secondly, a kernel-level exploit is like a local root "
+"exploit (worse in some ways), giving immediate and total access to the "
+"system right down to the hardware level."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1096
+msgid ""
+"That explains why you should never mount a filesystem from an untrusted "
+"guest on your host kernel. How about libguestfs? We run a Linux kernel "
+"inside a qemu virtual machine, usually running as a non-root user. The "
+"attacker would need to write a filesystem which first exploited the kernel, "
+"and then exploited either qemu virtualization (eg. a faulty qemu driver) or "
+"the libguestfs protocol, and finally to be as serious as the host kernel "
+"exploit it would need to escalate its privileges to root. This multi-step "
+"escalation, performed by a static piece of data, is thought to be extremely "
+"hard to do, although we never say 'never' about security issues."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1107
+msgid ""
+"In any case callers can reduce the attack surface by forcing the filesystem "
+"type when mounting (use L</guestfs_mount_vfs>)."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1110
+msgid "PROTOCOL SECURITY"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1112
+msgid ""
+"The protocol is designed to be secure, being based on RFC 4506 (XDR) with a "
+"defined upper message size. However a program that uses libguestfs must "
+"also take care - for example you can write a program that downloads a binary "
+"from a disk image and executes it locally, and no amount of protocol "
+"security will save you from the consequences."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1118
+msgid "INSPECTION SECURITY"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1120
+msgid ""
+"Parts of the inspection API (see L</INSPECTION>) return untrusted strings "
+"directly from the guest, and these could contain any 8 bit data. Callers "
+"should be careful to escape these before printing them to a structured file "
+"(for example, use HTML escaping if creating a web page)."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1126
+msgid ""
+"Guest configuration may be altered in unusual ways by the administrator of "
+"the virtual machine, and may not reflect reality (particularly for untrusted "
+"or actively malicious guests). For example we parse the hostname from "
+"configuration files like C</etc/sysconfig/network> that we find in the "
+"guest, but the guest administrator can easily manipulate these files to "
+"provide the wrong hostname."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1134
+msgid ""
+"The inspection API parses guest configuration using two external libraries: "
+"Augeas (Linux configuration) and hivex (Windows Registry). Both are "
+"designed to be robust in the face of malicious data, although denial of "
+"service attacks are still possible, for example with oversized configuration "
+"files."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1140
+msgid "RUNNING UNTRUSTED GUEST COMMANDS"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1142
+msgid ""
+"Be very cautious about running commands from the guest. By running a "
+"command in the guest, you are giving CPU time to a binary that you do not "
+"control, under the same user account as the library, albeit wrapped in qemu "
+"virtualization. More information and alternatives can be found in the "
+"section L</RUNNING COMMANDS>."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1148
+msgid "CVE-2010-3851"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1150
+msgid "https://bugzilla.redhat.com/642934"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1152
+msgid ""
+"This security bug concerns the automatic disk format detection that qemu "
+"does on disk images."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1155
+msgid ""
+"A raw disk image is just the raw bytes, there is no header. Other disk "
+"images like qcow2 contain a special header. Qemu deals with this by looking "
+"for one of the known headers, and if none is found then assuming the disk "
+"image must be raw."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1160
+msgid ""
+"This allows a guest which has been given a raw disk image to write some "
+"other header. At next boot (or when the disk image is accessed by "
+"libguestfs) qemu would do autodetection and think the disk image format was, "
+"say, qcow2 based on the header written by the guest."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1165
+msgid ""
+"This in itself would not be a problem, but qcow2 offers many features, one "
+"of which is to allow a disk image to refer to another image (called the "
+"\"backing disk\"). It does this by placing the path to the backing disk "
+"into the qcow2 header. This path is not validated and could point to any "
+"host file (eg. \"/etc/passwd\"). The backing disk is then exposed through "
+"\"holes\" in the qcow2 disk image, which of course is completely under the "
+"control of the attacker."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1173
+msgid "In libguestfs this is rather hard to exploit except under two circumstances:"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1180
+msgid "You have enabled the network or have opened the disk in write mode."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1184
+msgid ""
+"You are also running untrusted code from the guest (see L</RUNNING "
+"COMMANDS>)."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1189
+msgid ""
+"The way to avoid this is to specify the expected disk format when adding "
+"disks (the optional C<format> option to L</guestfs_add_drive_opts>). You "
+"should always do this if the disk is raw format, and it's a good idea for "
+"other cases too."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1194
+msgid ""
+"For disks added from libvirt using calls like L</guestfs_add_domain>, the "
+"format is fetched from libvirt and passed through."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1197
+msgid ""
+"For libguestfs tools, use the I<--format> command line parameter as "
+"appropriate."
+msgstr ""
+
+# type: =head1
+#: ../src/guestfs.pod:1200
+msgid "CONNECTION MANAGEMENT"
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1202
+msgid "guestfs_h *"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1204
+msgid ""
+"C<guestfs_h> is the opaque type representing a connection handle. Create a "
+"handle by calling L</guestfs_create>. Call L</guestfs_close> to free the "
+"handle and release all resources used."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1208
+msgid ""
+"For information on using multiple handles and threads, see the section "
+"L</MULTIPLE HANDLES AND MULTIPLE THREADS> below."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1211
+msgid "guestfs_create"
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1213
+#, no-wrap
+msgid ""
+" guestfs_h *guestfs_create (void);\n"
+"\n"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1215
+msgid "Create a connection handle."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1217
+msgid ""
+"You have to call L</guestfs_add_drive_opts> (or one of the equivalent calls) "
+"on the handle at least once."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1220
+msgid ""
+"This function returns a non-NULL pointer to a handle on success or NULL on "
+"error."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1223
+msgid "After configuring the handle, you have to call L</guestfs_launch>."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1225
+msgid ""
+"You may also want to configure error handling for the handle. See L</ERROR "
+"HANDLING> section below."
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1228
+msgid "guestfs_close"
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1230
+#, no-wrap
+msgid ""
+" void guestfs_close (guestfs_h *g);\n"
+"\n"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1232
+msgid "This closes the connection handle and frees up all resources used."
+msgstr ""
+
+# type: =head1
+#: ../src/guestfs.pod:1234
+msgid "ERROR HANDLING"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1236
+msgid ""
+"API functions can return errors. For example, almost all functions that "
+"return C<int> will return C<-1> to indicate an error."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1239
+msgid ""
+"Additional information is available for errors: an error message string and "
+"optionally an error number (errno) if the thing that failed was a system "
+"call."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1243