Bug 639599

Created attachment 451242 [details]
This patch validates the guest domain name even-though it contains "#" in it.

*** Bug 638962 has been marked as a duplicate of this bug. ***

The domain XML schema should enforce very few, if any, limits on what a domain
can be named.  Any restrictions on name should be enforced by the hypervisor
driver, or, IMO, preferably the hypervisor itself.

(In reply to comment #6)
> The domain XML schema should enforce very few, if any, limits on what a domain
> can be named.  Any restrictions on name should be enforced by the hypervisor
> driver, or, IMO, preferably the hypervisor itself.

I'd favor just removing the checks on name validity, or we should document and enforce our own check so that a domain can't be created with an invalid name, but I could be convinced otherwise.  DV, what's your take on this question?

We do need some reasonable checking; for example, since we create $domname.log, if $domname contains '/' (or worse, consecutive '/'), then it doesn't map well to the file system, and the log file no longer matches the domain name.  But the XML should probably be a lot more permissive, and I don't know if the full restrictions should be implemented per-hypervisor instead of at the generic domain_conf parser.

(In reply to comment #13)
> We do need some reasonable checking; for example, since we create $domname.log,
> if $domname contains '/' (or worse, consecutive '/'), then it doesn't map well
> to the file system, and the log file no longer matches the domain name.  But
> the XML should probably be a lot more permissive, and I don't know if the full
> restrictions should be implemented per-hypervisor instead of at the generic
> domain_conf parser.

That's different from the RNG validation, though, no?

(In reply to comment #15)
> (In reply to comment #13)
> > We do need some reasonable checking; for example, since we create $domname.log,
> > if $domname contains '/' (or worse, consecutive '/'), then it doesn't map well
> > to the file system, and the log file no longer matches the domain name.  But
> > the XML should probably be a lot more permissive, and I don't know if the full
> > restrictions should be implemented per-hypervisor instead of at the generic
> > domain_conf parser.
> 
> That's different from the RNG validation, though, no?

Correct - there's two issues at play:
1. RNG is too strict - the code accepts things that RNG rejects
2. the code is too loose - it accepts things that don't make sense

This BZ is about relaxing RNG.  It is okay if the RNG is looser than the code (that is, if it is too hard to write an RNG pattern that rejects consecutive slashes, then we can have that restriction live in just the code).  In other words, the quickest fix would be to have the RNG accept everything, then worry about tightening the code later (and possibly re-tightening the RNG to match code at that point).

The XML schema defining contents of the domain name field is relaxed by upstream commit:

commit 8a09ee4103400a47e2b6a763429288533cb8a97b
Author: Peter Krempa <pkrempa>
Date:   Mon Jan 23 18:41:44 2012 +0100

    schema: Relax schema for domain name
    
    The domain schema enforced restrictions on the domain name string that
    the code doesn't. This patch relaxes the check, leaving the restrictions
    on the driver or hypervisor. The only invalid character is a newline.

Verified PASS with libvirt-0.9.10-1.el6.

# cat /tmp/rhel62.xml 
<domain type='kvm'>
  <name>rhel62!@#$%^*()/\#_+":;'`,.</name>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
...snip...

# virt-xml-validate /tmp/rhel62.xml 
/tmp/rhel62.xml validates

For comment 25, only check the patch is okay on relaxing the check.
Definitely, can't start up a domain with the name in comment 25:-)

    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: 
Schema for the XML files contained stricter rules than those that were actually enforced by libvirt.

Consequence: 
Validation tools failed to validate guest XMLs that contained special characters in guest's name even if libvirt accepted the XML.

Fix:
The XML schema was relaxed to allow arbitrary strings with no limitation leaving the enforcement of rules on the hypervisor driver.

Result:
Users are able to validate that XMLs that are accepted by libvirt comply to the schemas.

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-0748.html