Bug 812092

Summary:	libguestfs cannot open disk images which are symlinks to files that contain ':' (colon) character
Product:	Red Hat Enterprise Linux 6	Reporter:	Richard W.M. Jones <rjones>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	dyasny, ilvovsky, leiwang, mbooth, moli, qguan, qwan, virt-maint, yuzhou
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libguestfs-1.16.18-2.el6	Doc Type:	Bug Fix
Doc Text:	Cause: qemu cannot open any disk image file that contains a ':' character. In addition, there were various bugs in libguestfs's handling and escaping of special characters in filenames. Consequence: libguestfs would sometimes invoke qemu incorrectly resulting in qemu failing to run, and libguestfs itself would sometimes refuse to open a disk image file even though it ought to be able to. Fix: All of the bugs in handling of filenames have been fixed. Result: Any filename can now be opened, except filenames that contains a ':' character (because qemu cannot open these: there is no fix for this qemu bug). libguestfs gives correct diagnostic messages when presented with a filename that contains a ':' character, and doesn't complain about any other character.	Story Points:	---
Clone Of:	811649	Environment:
Last Closed:	2012-06-20 07:01:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	811649
Bug Blocks:

Description Richard W.M. Jones 2012-04-12 18:12:45 UTC

+++ This bug was initially created as a clone of Bug #811649 +++

Reported by Igor Lvovsky.  This affects RHEV-M, so is important.

libguestfs cannot open a disk image where the file is a
symlink to a filename that contains a colon character.
Example:

  $ qemu-img create -f qcow2 normal 1G
  $ mv normal contains:colon
  $ ln -s contains\:colon symlink
  $ ls -l contains\:colon symlink 
  -rw-r--r--. 1 rjones rjones 197120 Apr 12 19:07 contains:colon
  lrwxrwxrwx. 1 rjones rjones     14 Apr 12 19:08 symlink -> contains:colon
  $ guestfish -a symlink run
  $ echo $?
  1

There are two, related problems.

(1) It is not possible to specify a filename that contains a
colon character on the qemu command line.  This is simply a bug
in qemu.

(2) libguestfs normalizes paths by calling 'realpath(3)'.

In the example above, (2) converts the filename 'symlink' to
a qemu command line option such as:

  qemu-kvm -drive file=/tmp/contains:colon,...

and that cannot be opened by qemu because of (1).

If we didn't normalize the paths, then this we wouldn't hit the
qemu problem, because the filename 'symlink' doesn't contain a
colon character.

It turns out that RHEV paths are always symlinks to filenames
that contain colons, so this bug especially affects RHEV.

Note also that this is a regression over RHEL 6.2.

Comment 2 Richard W.M. Jones 2012-04-12 18:36:03 UTC

Patch series posted here:
https://www.redhat.com/archives/libguestfs/2012-April/msg00060.html

Comment 3 Richard W.M. Jones 2012-04-13 07:33:45 UTC

The regression test had a bug so a fifth patch is also needed:
https://github.com/libguestfs/libguestfs/commit/4b0e525d1dcabe5ffc9b323103ee757be397abb0

Comment 5 Yuyu Zhou 2012-04-18 08:44:12 UTC

Verified with libguestfs-tools-1.16.18-2.el6.x86_64.

Before fix (libguestfs-tools-1.16.15-1.el6.x86_64):
1. a symlink (which does not contain colon) to a filename that contains a colon.
# qemu-img create -f qcow2 normal 1G
# mv normal contains:colon
# ln -s contains\:colon symlink
# guestfish -a symlink run
# echo $?
1

2. a symlink (whick contains conlon) to a filename that does not contains a colon.
# dd if=/dev/zero of=test1.img bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0162689 s, 645 MB/s
# ln -s test1.img file:file
# guestfish -a file\:file run
# echo $?
0

3. a filename contains a colon
# cp test1.img test1:1.img
# guestfish -a test1\:1.img run
# echo $?
1

After fix:
1. a symlink (which does not contain colon) to a filename that contains a colon.
# qemu-img create -f qcow2 normal 1G
# mv normal contains:colon
# ln -s contains\:colon symlink
# guestfish -a symlink run
# echo $?
0

2. a symlink (whick contains conlon) to a filename that does not contains a colon. (proper error message shows up)
# dd if=/dev/zero of=test1.img bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0162689 s, 645 MB/s
# ln -s test1.img file:file
# guestfish -a file\:file run
libguestfs: error: filename cannot contain ':' (colon) character. This is a limitation of qemu.

3. a filename contains a colon. (proper error message shows up)
# cp test1.img test1:1.img
# guestfish -a test1\:1.img run
libguestfs: error: filename cannot contain ':' (colon) character. This is a limitation of qemu.

Comment 6 Richard W.M. Jones 2012-04-26 13:52:49 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:
qemu cannot open any disk image file that contains a ':' character.  In addition, there were various bugs in libguestfs's handling and escaping of special characters in filenames.

Consequence:
libguestfs would sometimes invoke qemu incorrectly resulting in qemu failing to run, and libguestfs itself would sometimes refuse to open a disk image file even though it ought to be able to.

Fix:
All of the bugs in handling of filenames have been fixed.

Result:
Any filename can now be opened, except filenames that contains a ':' character (because qemu cannot open these: there is no fix for this qemu bug).  libguestfs gives correct diagnostic messages when presented with a filename that contains a ':' character, and doesn't complain about any other character.

Comment 8 errata-xmlrpc 2012-06-20 07:01:53 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0774.html