Various virStorageVol* API operate on user-supplied volume names by
concatenating the volume name to the pool location. Note that the
virStoragePoolListVolumes API, when used on a storage pool backed by
a directory in a file system, will only list volumes immediately in
that directory (there is no traversal into subdirectories). However,
other APIs such as virStorageVolCreateXML were not checking if a
potential volume name represented one of the volumes that could be
returned by virStoragePoolListVolumes; because they were not rejecting
the use of '/' in a volume name.
Because no checking was done on volume names, a user could supply
a potential volume name of something like '../../../etc/passwd' to
attempt to access a file not belonging to the storage pool. When
fine-grained Access Control Lists (ACL) are in effect, a user with
storage_vol:create ACL permission but lacking domain:write permission
could thus abuse virStorageVolCreateXML and similar APIs to gain
access to files not normally permitted to that user. Fortunately, it
appears that the only APIs that could leak information or corrupt
files require read-write connection to libvirtd; and when ACLs are not
in use (the default without any further configuration), a user with
read-write access can already be considered to have full access to the
machine, and without an escalation of privilege there is no security
problem.