[libvirt] [PATCH] Don't use O_TRUNC when opening QEMU logfiles

Jiri Denemark jdenemar at redhat.com
Fri Sep 21 09:51:06 UTC 2012


On Fri, Sep 21, 2012 at 10:39:19 +0100, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange at redhat.com>
> 
> SELinux wants all log files opened with O_APPEND. When
> running non-root though, libvirtd likes to use O_TRUNC
> to avoid log files growing in size indefinitely. Instead
> of using O_TRUNC though, we can use O_APPEND and then
> call ftruncate() which keeps SELinux happier.
> 
> Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
> ---
>  src/qemu/qemu_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 0ae30b7..e67c247 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -1446,12 +1446,22 @@ qemuDomainOpenLogHelper(struct qemud_driver *driver,
>  {
>      char *logfile;
>      int fd = -1;
> +    bool trunc = false;
>  
>      if (virAsprintf(&logfile, "%s/%s.log", driver->logDir, vm->def->name) < 0) {
>          virReportOOMError();
>          return -1;
>      }
>  
> +    /* To make SELinux happy we always need to open in append mode.
> +     * So we fake O_TRUNC by calling ftruncate after open instead
> +     */
> +    if (oflags & O_TRUNC) {
> +        oflags &= ~O_TRUNC;
> +        oflags |= O_APPEND;
> +        trunc = true;
> +    }
> +
>      if ((fd = open(logfile, oflags, mode)) < 0) {
>          virReportSystemError(errno, _("failed to create logfile %s"),
>                               logfile);
> @@ -1463,6 +1473,13 @@ qemuDomainOpenLogHelper(struct qemud_driver *driver,
>          VIR_FORCE_CLOSE(fd);
>          goto cleanup;
>      }
> +    if (trunc &&
> +        ftruncate(fd, 0) < 0) {
> +        virReportSystemError(errno, _("failed to truncate %s"),
> +                             logfile);
> +        VIR_FORCE_CLOSE(fd);
> +        goto cleanup;
> +    }

I wonder if it's necessary to fail here or if VIR_WARN would be sufficient.

ACK in any case.

Jirka




More information about the libvir-list mailing list