[libvirt] [PATCH] network: fix problems with SRV

[Laine Stump]

On 03/18/2014 01:09 AM, Martin Kletzander wrote:
> On Tue, Mar 18, 2014 at 12:07:17AM -0600, Laine Stump wrote:
>> A patch submitted by Steven Malin last week pointed out a problem with
>> libvirt's DNS SRV record configuration:
>>
>>   https://www.redhat.com/archives/libvir-list/2014-March/msg00536.html
>>
>> When searching for that message later, I found another series that had
>> been posted by Guannan Ren back in 2012 that somehow slipped between
>> the cracks:
>>
>>   https://www.redhat.com/archives/libvir-list/2012-July/msg00236.html
>>
>> That patch was very much out of date, but also pointed out some real
>> problems.
>>
>> This patch fixes all the noted problems by refactoring
>> virNetworkDNSSrvDefParseXML() and networkDnsmasqConfContents(), then
>> verifies those fixes by added several new records to the test case.
>>
>> Problems fixed:
>>
>> * both service and protocol now have an underscore ("_") prepended on
>>   the commandline, as required by RFC2782.
>>
>>   <srv service='sip' protocol='udp' domain='example.com'
>>        target='tests.example.com' port='5060' priority='10'
>>        weight='150'/>
>>
>>   before: srv-host=sip.udp.example.com,tests.example.com,5060,10,150
>>   after:  srv-host=_sip._udp.example.com,tests.example.com,5060,10,150
>>
>> * if "domain" wasn't specified in the <srv> element, the extra
>>   trailing "." will no longer be added to the dnsmasq commandline.
>>
>>   <srv service='sip' protocol='udp' target='tests.example.com'
>>        port='5060' priority='10' weight='150'/>
>>
>>   before: srv-host=sip.udp.,tests.example.com,5060,10,150
>>   after:  srv-host=_sip._udp,tests.example.com,5060,10,150
>>
>> * when optional attributes aren't specified, the separating comma is
>>   also now not placed on the dnsmasq commandline. If optional
>>   attributes in the middle of the line are not specified, they are
>>   replaced with 0 in the commandline.
>>
>>   <srv service='sip' protocol='udp' target='tests.example.com'
>>        port='5060'/>
>>
>>   before: srv-host=sip.udp.,tests.example.com,5060,,
>>   after:  srv-host=_sip._udp,tests.example.com,5060
>>
>>   (actually this would have generated an error, because "optional"
>>   attributes weren't really optional).
>>
>> * As a safeguard, the parser checks for a leading "_" on service and
>>   protocol, and fails if it is found. (Note that we can be guaranteed
>>   that no existing valid configuration will have this, since until
>>   now the parser had only allowed "tcp" or "udp" for protocol, and
>>   the bridge driver wasn't prepending "_", making it a 100% certainty
>>   that there was no example of working SRV record use in the wild).
>>
> That's valid for protocol, but not for service.  For service there was
> a check for length only and it was not escaped at all.  Even though
> there couldn't be any abuse for that, settings that resulted in
> generating invalid config file for dnsmasq were parsed and saved
> without any error from libvirt.

Just to make sure what I wrote made sense: my point was that, due to the
fact that the current code would only be able to generate records like this:


         [some-name].tcp.[some-domain]
         [some-name].udp.[some-domain]

(i.e. the protocol could only be the exact string "tcp" or "udp"), and
since the RFC *requires* that the protocol be prefixed with an
underscore, it is impossible that anyone has an actual working config
using the existing code (although it may have been saved with no error,
it wouldn't do anything useful). Because it is impossible that it could
have worked before, we don't need to worry about backward compatibility
problems - nothing we do could break a working config.

But I *think* what you're pointing out is that, although the config may
not be working, it's possible that someone could have made a config like
this:

   <srv service='_sip' protocol='udp' domain='example.com'
target='sip.example.com' port='5060'/>

which they could have saved, even though it would do nothing useful, it
would be saved. Then when that system was updated to the new libvirt,
that network's config would generate an error while loading, so the
network would be ignored. Gah!!

So I *can't* add this new restriction in the parser. I could check for
it during networkValidate() in the bridge driver, though. Do you think
this is worthwhile? (I think I'll do it as a separate patch in any case).


>> -
>> -    /* Check whether protocol value is the supported one */
>> -    if (def->protocol && STRNEQ(def->protocol, "tcp") &&
>> -        (STRNEQ(def->protocol, "udp"))) {
>> +    if (def->protocol && def->protocol[0] == '_') {
>>          virReportError(VIR_ERR_XML_DETAIL,
> I'm not sure we want to allow anything not starting with '_'.  OTOH,
> we allowed anything in the service (even dots and commas and so on
> (non-working configuration).

I was bothered by this as well, and spent quite awhile searching RFCs to
get a definitive answer on what characters are allowed in a service name
or a protocol name. I couldn't find this information, though. I could
only find lists of currently assigned service/protocol names. I guess
since it is the number that goes over the wire, the RFCs are more
concerned about the number than about exactly what it is called (dhcp
option names suffer the same problem - there are only official option
*numbers*, but not official names).

I then considered limiting the character set to what can currently be
found in /etc/services and /etc/protocol on a Linux system, but after
taking a quick look, it seemed like there wasn't a very strict code
about it - there are even some names that use "+".

Eric did find a bit in "man services" that says that basically any
printable ASCII character is okay, but you should be conservative in
what you use (didn't stop people from adding things like "sql*net" and
"whois++" to /etc/services, though :-/)

So how about this - I will define a character set that contains only
alphanumerics, and those special characters currently used in
/etc/services and /etc/protocol, and check it against that. (except ".",
because dnsmasq uses that as a separator on the commandline, and there
is no method of escaping it).

(As discussed above, I have to remove the restriction on _ as the
leading character.)

>> +            if (dns->srvs[i].port ||
>> +                dns->srvs[i].priority || dns->srvs[i].weight)
>> +                virBufferAsprintf(&configbuf, ",%d", dns->srvs[i].port);
> According to dnsmasq(1), port defaults to 1, but you default it here
> to 0, which doesn't make sense.

Good point, and although our config should be affected by the RFC rather
than by dnsmasq, the RFC doesn't say anything about default values
because in the DNS record all the fields are mandatory. Since a service
for port 0 makes no sense (port 0 is reserved for both tcp and udp), I
think we can safely make the value "0" mean "unspecified, use default of
1", and then disallow config with an explicit "port='0'" to avoid
ambiguity. Then if we need to put something on the commandline to fill
the space, we will put "1" instead of "0".

I'll squash in the changes in the attached patch and send a v2.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Changes-to-squash-into-SRV-patch.patch
Type: text/x-patch
Size: 6027 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140319/33484b82/attachment-0001.bin>