[libvirt] [PATCH 3/3] Create storage volumes directly with desired uid/gid.

Daniel P. Berrange berrange at redhat.com
Tue Jan 12 12:36:20 UTC 2010


On Mon, Jan 11, 2010 at 12:46:12AM -0500, Laine Stump wrote:
> In order to avoid problems trying to chown files that were created by
> root on a root-squashing nfs server, fork a new process that setuid's
> to the desired uid before creating the file. (It's only done this way
> if the pool containing the new volume is of type 'netfs', otherwise
> the old method of creating the file followed by chown() is used.)
> 
> This changes the semantics of the "create_func" slightly - previously
> it was assumed that this function just created the file, then the
> caller would chown it to the desired uid. Now, create_func does both
> operations.
> 
> There are multiple functions that can take on the role of create_func:
> 
> createFileDir - previously called mkdir(), now calls virDirCreate().
> virStorageBackendCreateRaw - previously called open(),
>                              now calls virFileCreate().
> virStorageBackendCreateQemuImg - use virRunWithHook() to setuid/gid.
> virStorageBackendCreateQcowCreate - same.
> virStorageBackendCreateBlockFrom - preserve old behavior.
> ---
>  src/storage/storage_backend.c    |  115 ++++++++++++++++++++++++++++++++------
>  src/storage/storage_backend.h    |    4 +
>  src/storage/storage_backend_fs.c |   48 ++++++++++------
>  3 files changed, 132 insertions(+), 35 deletions(-)


[snip]

> @@ -840,7 +833,15 @@ _virStorageBackendFileSystemVolBuild(virConnectPtr conn,
>  static int
>  virStorageBackendFileSystemVolBuild(virConnectPtr conn,
>                                      virStorageVolDefPtr vol) {
> -    return _virStorageBackendFileSystemVolBuild(conn, vol, NULL);
> +    return _virStorageBackendFileSystemVolBuild(conn, vol, NULL, 0);
> +}
> +
> +/* version for vols created in netfs-based pools */
> +static int
> +virStorageBackendFileSystemNetVolBuild(virConnectPtr conn,
> +                                       virStorageVolDefPtr vol) {
> +    return _virStorageBackendFileSystemVolBuild(conn, vol, NULL,
> +                                                VIR_STORAGE_BUILD_NETFS);
>  }
>  
>  /*
> @@ -851,9 +852,20 @@ virStorageBackendFileSystemVolBuildFrom(virConnectPtr conn,
>                                          virStorageVolDefPtr vol,
>                                          virStorageVolDefPtr inputvol,
>                                          unsigned int flags ATTRIBUTE_UNUSED) {
> -    return _virStorageBackendFileSystemVolBuild(conn, vol, inputvol);
> +    return _virStorageBackendFileSystemVolBuild(conn, vol, inputvol, 0);
> +}
> +
> +/* version for vols created in netfs-based pools */
> +static int
> +virStorageBackendFileSystemNetVolBuildFrom(virConnectPtr conn,
> +                                           virStorageVolDefPtr vol,
> +                                           virStorageVolDefPtr inputvol,
> +                                           unsigned int flags ATTRIBUTE_UNUSED) {
> +    return _virStorageBackendFileSystemVolBuild(conn, vol, inputvol,
> +                                                VIR_STORAGE_BUILD_NETFS);
>  }


I think I'd be inclined to edit storage_backend.h and change the 

  typedef int (*virStorageBackendBuildVol)(virConnectPtr conn, virStorageVolDefPtr vol);

to

  typedef int (*virStorageBackendBuildVol)(virConnectPtr conn, virStoragePoolObjPtr pool, virStorageVolDefPtr vol);

so that the build method has direct access to the pool type. Likewise
for the BuildFrom method prototype. Once that change ripples through
all the code, the place where you need to distinguish local vs net
filesytem will have access to the pool object it wants


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list