Patchwork [2/2] qga: try to unlink just created guest-file if fchmod() fails on it

login
register
mail settings
Submitter Eric Blake
Date May 7, 2013, 5:30 p.m.
Message ID <51893A22.1040105@redhat.com>
Download mbox | patch
Permalink /patch/242432/
State New
Headers show

Comments

Eric Blake - May 7, 2013, 5:30 p.m.
On 05/07/2013 10:56 AM, Laszlo Ersek wrote:
> We shouldn't allow guest filesystem pollution on error paths.
> 
> Suggested-by: Eric Blake <eblake@redhat.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>  qga/commands-posix.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> index 2eec712..d301b1f 100644
> --- a/qga/commands-posix.c
> +++ b/qga/commands-posix.c
> @@ -341,6 +341,7 @@ safe_open_or_create(const char *path, const char *mode, Error **err)
>                  error_setg_errno(&local_err, errno, "failed to set permission "
>                                   "0%03o on new file '%s' (mode: '%s')",
>                                   (unsigned)DEFAULT_NEW_FILE_MODE, path, mode);
> +                unlink(path);

This fixes the case of a mode 0000 file if fchmod fails, but doesn't fix
the case of a mode 0666 file if fchmod succeeds but fdopen fails.  It
also requires that unlink() while open works (true for most Unix
systems, but false for Windows systems and not required by POSIX - but
see my realization on 1/2 that this file isn't compiled on Windows). I
think you want this instead:
Laszlo Ersek - May 8, 2013, 12:35 a.m.
On 05/07/13 19:30, Eric Blake wrote:
> On 05/07/2013 10:56 AM, Laszlo Ersek wrote:
>> We shouldn't allow guest filesystem pollution on error paths.
>>
>> Suggested-by: Eric Blake <eblake@redhat.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>  qga/commands-posix.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
>> index 2eec712..d301b1f 100644
>> --- a/qga/commands-posix.c
>> +++ b/qga/commands-posix.c
>> @@ -341,6 +341,7 @@ safe_open_or_create(const char *path, const char *mode, Error **err)
>>                  error_setg_errno(&local_err, errno, "failed to set permission "
>>                                   "0%03o on new file '%s' (mode: '%s')",
>>                                   (unsigned)DEFAULT_NEW_FILE_MODE, path, mode);
>> +                unlink(path);
> 
> This fixes the case of a mode 0000 file if fchmod fails, but doesn't fix
> the case of a mode 0666 file if fchmod succeeds but fdopen fails.  It
> also requires that unlink() while open works (true for most Unix
> systems, but false for Windows systems and not required by POSIX

Please provide a reference for "not required by POSIX". The EBUSY
condition I'm looking at says "The file named by the path argument
cannot be unlinked because it is being used by the system or another
process and the implementation considers this an error".

"Used by the system or another process" shouldn't really be the case here.

 - but
> see my realization on 1/2 that this file isn't compiled on Windows). I
> think you want this instead:
> 
> diff --git i/qga/commands-posix.c w/qga/commands-posix.c
> index 04c6951..89cc6d8 100644
> --- i/qga/commands-posix.c
> +++ w/qga/commands-posix.c
> @@ -345,6 +345,9 @@ safe_open_or_create(const char *path, const char
> *mode, Error **err)
>              }
> 
>              close(fd);
> +	    if (oflag & O_CREAT) {
> +	        unlink(path);
> +	    }
>          }
>      }
> 

I'll give myself some time on this. Clearly if I rush a patch I make a mess.

Thanks,
Laszlo
Eric Blake - May 8, 2013, 2:24 a.m.
On 05/07/2013 06:35 PM, Laszlo Ersek wrote:
>> This fixes the case of a mode 0000 file if fchmod fails, but doesn't fix
>> the case of a mode 0666 file if fchmod succeeds but fdopen fails.  It
>> also requires that unlink() while open works (true for most Unix
>> systems, but false for Windows systems and not required by POSIX
> 
> Please provide a reference for "not required by POSIX". The EBUSY
> condition I'm looking at says "The file named by the path argument
> cannot be unlinked because it is being used by the system or another
> process and the implementation considers this an error".

That's precisely what I'm looking at.  The Windows implementation
considers any open file as in use by the system, and gives an error when
trying to unlink an open file (it also gives an error when trying to
rmdir a directory that serves as the current working directory of any
process).

Another case is NFS, which has historically had not-so-nice behavior if
you attempt to unlink an open file (such as the file still being
resident in cache for several seconds longer and preventing removal of a
directory), whereas closing first and then unlinking suffers from no
delay or weird caching effects (admittedly, NFS as a file system breaks
several POSIX rules).

You are right that POSIX unlink() also says "If one or more processes
have the file open when the last link is removed, the link shall be
removed before unlink() returns, but the removal of the file contents
shall be postponed until all references to the file are closed."  But I
read that as permitting (but not requiring) an implementation to unlink
an open fd, if it further follows the rules about the file contents when
unlinking an open file.  Meanwhile, the EBUSY error permits (but not
requires) implementations to let unlink fail on an open file, and NFS
serves as a case study of this behavior even on Unix-y systems.

Even if you don't buy my argument about EBUSY, and even though we both
agree that Unix-y systems have historically allowed unlink of an open
file on a local file system (as well as rmdir of the current working
directory), it still doesn't change the fact that in reality, such
actions are not portable to Windows or NFS.  And whether or not Windows
is non-compliant with POSIX doesn't matter quite as much as whether our
code is portable to the systems we are porting to.

> 
> "Used by the system or another process" shouldn't really be the case here.

Used by another process - no.  Used by the system - yes, if the system
considers all open files to be in use.

Patch

diff --git i/qga/commands-posix.c w/qga/commands-posix.c
index 04c6951..89cc6d8 100644
--- i/qga/commands-posix.c
+++ w/qga/commands-posix.c
@@ -345,6 +345,9 @@  safe_open_or_create(const char *path, const char
*mode, Error **err)
             }

             close(fd);
+	    if (oflag & O_CREAT) {
+	        unlink(path);
+	    }
         }
     }