Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1132191 - [Windows sysprep] Run Once: Special characters are not encoded in XML sysprep files for Windows 7, 8, 2008, 2012
Summary: [Windows sysprep] Run Once: Special characters are not encoded in XML sysprep...
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.0
Hardware: x86_64
OS: All
Target Milestone: ---
: 3.5.0
Assignee: Shahar Havivi
QA Contact: Pavel Novotny
Whiteboard: virt
Depends On: 1122160
Blocks: 1135920 rhev3.5beta 1156165
TreeView+ depends on / blocked
Reported: 2014-08-20 21:15 UTC by Jake Hunsaker
Modified: 2019-03-22 07:17 UTC (History)
14 users (show)

Fixed In Version: vt2.2
Doc Type: Bug Fix
Doc Text:
Clone Of: 1122160
: 1135920 (view as bug list)
Last Closed: 2015-02-11 18:08:28 UTC
oVirt Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC
oVirt gerrit 31957 None None None Never
oVirt gerrit 31973 None None None Never
oVirt gerrit 31974 ovirt-engine-3.4 MERGED backend: sysprep custom variables should be in CDATA section Never

Description Jake Hunsaker 2014-08-20 21:15:25 UTC
+++ This bug was initially created as a clone of Bug #1122160 +++

Description of problem:
When running a sealed Windows 7/7x64/8/8x64/2008/2008x64/2012x64 VM with sysprep floppy attached, all values provided from Run Once dialog are put in the sysprep file as plain-text, even when these Windows versions are using XML format for sysprep file, thus allowing to create a syntactically incorrect sysprep file.

Version-Release number of selected component (if applicable):
ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch (beta)

How reproducible:

Steps to Reproduce:
1. Have a "sealed" Windows VM, any of version 7, 7x64, 8, 8x64, 2008, 2008x64 or 2012x64
2. In Run Once dialog enter as the Admin Password value 'pass</word>'
3. Run the VM and watch the Windows initialization process

Actual results:
The Windows initialization fails on a parsing error of the unattend file.
If you check it (A:\sysprep.inf), you see the admin password is put in the XML as plain-text:


Expected results:
For Windows versions using XML sysprep files, all special characters should be encoded, such as: in GUI enter value 'pass</word>' and in sysprep file will be value 'pass&lt;/word&gt;'.

Additional info:

+++ End of cloned data +++

Cloning this to RHEV. This has been seen as far back as 3.2 and in this case 'Run Once' was *not* used.

Comment 2 Eyal Edri 2014-08-31 08:14:07 UTC
can you please clone the bug to 3.4.z?
also i see the master/3.5 patch is missing from the bug.

Comment 3 Michal Skrivanek 2014-09-01 07:44:18 UTC
(In reply to Eyal Edri from comment #2)
patches on 3.5/master are using the corresponding oVirt bug

Comment 6 Pavel Novotny 2014-09-12 15:37:11 UTC
Verified in rhevm-3.5.0-0.11.beta.el6ev.noarch (vt3).

All variables in XML sysprep template files are now placed into CDATA section so all characters are represented the same way as they are entered.
For example password 'pass</word>' now doesn't cause parsing error and it's set in the Windows guest.
Note that the above doesn't apply to *custom* sysprep file, where user has to take care about the sysprep file validity by himself.

Comment 8 errata-xmlrpc 2015-02-11 18:08:28 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.

Note You need to log in before you can comment on or make changes to this bug.