On Mon, Sep 07, 2009 at 04:12:39PM +0200, Miloslav Trmač wrote:
> This implementation stores the secrets in an unencrypted text file,
> for simplicity in implementation and debugging.
>
> (Symmetric encryption, e.g. using gpgme, will not be difficult to add.
> Because the TLS private key used by libvirtd is stored unencrypted,
> encrypting the secrets file does not currently provide much additional
> security.)
>
> Changes since the fourth submission:
> - Rewrite storage mechanism to use one or two files per secret
> - Use the separate virSecretDef API for XML manipulation
> - Update for <usage type='volume'><volume/></usage>
> - Replace the "libvirt_internal_call" parameter of setValue() by
> VIR_SECRET_GET_VALUE_INTERNAL_CALL.
> - Fix comment in src/libvirt_private.syms
>
> * include/libvirt/virterror.h, src/virterror.c (VIR_ERR_NO_SECRET): New
> error number.
> * po/POTFILES.in, src/Makefile.am: Add secret_driver.
> * bootstrap: Use gnulib's base64 module.
> * src/secret_driver.c, src.secret_driver.h, src/libvirt_private.syms:
> Add local secret driver.
> * qemud/qemud.c (qemudInitialize): Use the local secret driver.
> ---
> bootstrap | 1 +
> include/libvirt/virterror.h | 1 +
> po/POTFILES.in | 1 +
> qemud/qemud.c | 3 +
> src/Makefile.am | 14 +
> src/libvirt_private.syms | 3 +
> src/secret_driver.c | 1060 +++++++++++++++++++++++++++++++++++++++++++
> src/secret_driver.h | 28 ++
> src/virterror.c | 5 +
> 9 files changed, 1116 insertions(+), 0 deletions(-)
> create mode 100644 src/secret_driver.c
> create mode 100644 src/secret_driver.h
>
> diff --git a/bootstrap b/bootstrap
> index 8b81e0e..885b299 100755
> --- a/bootstrap
> +++ b/bootstrap
> @@ -65,6 +65,7 @@ gnulib_tool=$GNULIB_SRCDIR/gnulib-tool
> <$gnulib_tool || exit
>
> modules='
> +base64
Argh !
.gnulib/lib/base64.c
"This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version."
Looks like GPL code not LGPL, I'm not sure we can actually use it,
Jim any opinion ?
We have some base64 code in libxml2 but it's not part of the
exported APIs
[...]
> + if (rename(tmp_path, filename) < 0) {
> + virReportSystemError(conn, errno, _("rename(%s, %s) failed"), tmp_path,
> + filename);
> + goto cleanup;
> + }
> + VIR_FREE(tmp_path);
> + ret = 0;
Okay, I had to convince myself this was correct but with the
initialization of tmp_path fine :-)
[...]
> +static int
> +secretLoadValue(virConnectPtr conn, virSecretDriverStatePtr driver,
> + virSecretEntryPtr secret)
> +{
> + int ret = -1, fd = -1;
> + struct stat st;
> + char *filename = NULL, *contents = NULL, *value = NULL;
> + size_t value_size;
> +
> + filename = secretBase64Path(conn, driver, secret);
> + if (filename == NULL)
> + goto cleanup;
> +
> + fd = open(filename, O_RDONLY);
> + if (fd == -1) {
> + if (errno == ENOENT) {
> + ret = 0;
> + goto cleanup;
> + }
> + virReportSystemError (conn, errno, _("cannot open '%s'"), filename);
> + goto cleanup;
> + }
> + if (fstat(fd, &st) < 0) {
> + virReportSystemError (conn, errno, _("cannot stat '%s'"), filename);
> + goto cleanup;
> + }
> + if ((size_t)st.st_size != st.st_size) {
shouldn't we chaeck against SECRET_MAX_XML_FILE instead ?
> + virSecretReportError(conn, VIR_ERR_INTERNAL_ERROR,
> + _("'%s' file does not fit in memory"), filename);
> + goto cleanup;
> + }
ACK once we have cleared the status of the base64 gnulib dependancy
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list