On 02/07/2013 07:57 AM, John Ferlan wrote:
> On 02/07/2013 08:27 AM, Christophe Fergeau wrote:
>> Similarly to 790f912b4 which rejects snapshots names containing,
>> this commit changes virDomainSaveXML to reject domains with a '/'
>> in their name. The domain name is used as a filename, so this
>> leads to unexpected results when used in combination with '..'
>> ---
>> src/conf/domain_conf.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>> index 85a798d..13f4bc0 100644
>> --- a/src/conf/domain_conf.c
>> +++ b/src/conf/domain_conf.c
>> @@ -14728,6 +14728,13 @@ int virDomainSaveXML(const char *configDir,
>> char *configFile = NULL;
>> int ret = -1;
>>
>> + if (strchr(def->name, '/')) {
>> + virReportError(VIR_ERR_XML_DETAIL,
>> + _("invalid domain name '%s': name can't contain '/'"),
>> + def->name);
>> + goto cleanup;
>> + }
>> +
>> if ((configFile = virDomainConfigFile(configDir, def->name)) == NULL)
>> goto cleanup;
>>
>>
> Seems this should be in a more "general" location. Would the same rules apply to
> other objects (networks, storage, etc.)? What other characters should be avoided?
In my mind, newline is the most questionable remaining character; as
long as a user has proper shell quoting, and we limit things to one file
per line, then all other file names are at least usable even if they
remain questionable for ability to type easily.
> Having a comma, semi-colon, colon, etc. could have interesting results. Perhaps
> somewhat different rules for each, but using some sort of type of object enum
> to weed out object specific rules (eg, VIR_IS_ type macros).
Indeed, a series of followup patches to make these types of restrictions
more generic might be nice; but I don't think we need to wait for a
followup in order to apply this series as-is.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list