[Libvir] [PATCH]Reprt error for a existing file

Kazuki Mizushima mizushima.kazuk at jp.fujitsu.com
Tue Mar 6 04:55:19 UTC 2007


Hi, Rich

Thank you for reply and I understand you.
I am lacking of REMOTE point of view, 
so this patch is not work for a remote hypervisor. 
And I also understand that this issue is not to be able to deal with libvirt.

> My other problem is the use of stat(2) (or access) to determine if a
> file exists, since we up on slippy ground if this is relied upon in a
> security-related context.  It's better to make the atomic open(2) call
> fail instead (which is actually what happens in current libxc).

Thank you for your indication.
I misunderstand that xenXMDriver uses stat whether file is existing or not.
The xenXMDriver uses it which isn't a file(S_ISREG).

Thanks,
Kazuki Mizushima

----- Original Message ----- 
From: "Richard W.M. Jones" <rjones at redhat.com>
To: <libvir-list at redhat.com>
Sent: Monday, March 05, 2007 8:30 PM
Subject: Re: [Libvir] [PATCH]Reprt error for a existing file


> Kazuki Mizushima wrote:
>> Hi,
>> I make a patch which reports error for a existing file to prevent 
>> overwriting before the file.
>> 
>> # ./virsh dump 1 a.dump
>> error: file a.dump exists already
> 
>> @@ -871,6 +873,11 @@ cmdSave(vshControl * ctl, vshCmd * cmd)
>>     if (!(dom = vshCommandOptDomain(ctl, cmd, "domain", &name)))
>>         return FALSE;
>> 
>> +    if (stat(to, &st) == 0){
>> +        vshError(ctl, FALSE, _("file %s exists already"), to);
>> +        return FALSE;
>> +    }
>> +
>>     if (virDomainSave(dom, to) == 0) {
>>         vshPrint(ctl, _("Domain %s saved to %s\n"), name, to);
>>     } else {
> 
> I guess I have a few problems with this patch.  Currently only the xend
> driver actually supports saving domains (remote will support it in the
> next version too).  And it does it by making the path absolute and
> sending an instruction to xend, so the save is done out of process and
> is essentially outside the control of libvirt (ie. the behaviour of xend
> might change in the future).
> 
> So (IMHO) the questions are:
> (a) what should the behaviour of virDomainSave be when the file already
> exists?
> (b) where should we enforce that behaviour?
> (c) what behaviours can we support in the underlying drivers?
> 
> If we accept that virDomainSave should always overwrite the dump file
> (question (a)), can we support that (question (c) - my reading of the
> source of libxc is that Xen itself won't overwrite files, but libvirt's
> xend driver can certainly be modified to delete the file first), and
> where should we enforce it (question (b) - in libvirt's xend driver).
> 
> If, on the other hand, we want virDomainSave to never overwrite dump
> files and core files, then we should probably add a check in the drivers
> which support the methods (xend and remote) so that they fail under such
> conditions with a decent error message.
> 
> My other problem is the use of stat(2) (or access) to determine if a
> file exists, since we up on slippy ground if this is relied upon in a
> security-related context.  It's better to make the atomic open(2) call
> fail instead (which is actually what happens in current libxc).
> 
> Rich.
> 
> --
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>




More information about the libvir-list mailing list