qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "M. Mohan Kumar" <mohan@in.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [V7 PATCH 9/9] virtio-9p: Chroot environment for other functions
Date: Wed, 9 Mar 2011 13:40:52 +0530	[thread overview]
Message-ID: <201103091340.53088.mohan@in.ibm.com> (raw)
In-Reply-To: <AANLkTik0KiEtc5_g+fUue=_ox-ZC2O4PQhHvvcb_hHPq@mail.gmail.com>


Thanks Stefan for your review!

On Friday 04 March 2011 5:22:00 pm Stefan Hajnoczi wrote:
> 
> Is this code supposed to build on non-Linux hosts?  If so, then please
> confirm that the *at() system calls used are standard and available on
> other hosts (e.g. FreeBSD, Darwin, Solaris).
> 
No, this (virtio-9p) is not supported on non-linux hosts.

> > +/*
> > + * Returns file descriptor of dirname(path)
> > + * This fd can be used by *at functions
> > + */
> > +static int get_dirfd(FsContext *fs_ctx, const char *path)
> > +{
> > +    V9fsFileObjectRequest request;
> > +    int fd;
> > +    char *dpath = qemu_strdup(path);
> > +
> > +    fd = fill_fileobjectrequest(&request, dirname(dpath), NULL);
> > +    if (fd < 0) {
> > +        return fd;
> > +    }
> 
> Leaks dpath, fails to set errno, and does not return -1.
Will fix in next patchset.

> 
> > @@ -545,53 +621,146 @@ static int local_link(FsContext *fs_ctx, const
> > char *oldpath,
> > 
> >  static int local_truncate(FsContext *ctx, const char *path, off_t size)
> >  {
> > -    return truncate(rpath(ctx, path), size);
> > +    if (ctx->fs_sm == SM_PASSTHROUGH) {
> > +        int fd, retval;
> > +        fd = passthrough_open(ctx, path, O_RDWR);
> > +        if (fd < 0) {
> > +            return -1;
> > +        }
> > +        retval = ftruncate(fd, size);
> > +        close(fd);
> > +        return retval;
> 
> This is an example of where errno is not guaranteed to be preserved.
> When ftruncate(2) fails close(2) is allowed to affect errno and we
> cannot rely on it holding the ftruncate(2) error code.  Please check
> for other cases of this.
Will fix in next patchset.
> 
> >  static int local_rename(FsContext *ctx, const char *oldpath,
> >                         const char *newpath)
> >  {
> > -    char *tmp;
> > -    int err;
> > -
> > -    tmp = qemu_strdup(rpath(ctx, oldpath));
> > +    int err, serrno = 0;
> > 
> > -    err = rename(tmp, rpath(ctx, newpath));
> > -    if (err == -1) {
> > -        int serrno = errno;
> > -        qemu_free(tmp);
> > +    if (ctx->fs_sm == SM_PASSTHROUGH) {
> > +        int opfd, npfd;
> > +        char *old_tmppath, *new_tmppath;
> > +        opfd = get_dirfd(ctx, oldpath);
> > +        if (opfd < 0) {
> > +            return -1;
> > +        }
> > +        npfd = get_dirfd(ctx, newpath);
> > +        if (npfd < 0) {
> > +            close(opfd);
> > +            return -1;
> > +        }
> > +        old_tmppath = qemu_strdup(oldpath);
> > +        new_tmppath = qemu_strdup(newpath);
> > +        err = renameat(opfd, basename(old_tmppath),
> > +                        npfd, basename(new_tmppath));
> > +        if (err == -1) {
> > +            serrno = errno;
> > +        }
> > +        close(npfd);
> > +        close(opfd);
> > +        qemu_free(old_tmppath);
> > +        qemu_free(new_tmppath);
> >         errno = serrno;
> 
> Why can't this be done as a chroot worker operation in a single syscall?
Ok, in next patchset, T_RENAME & T_REMOVE types will be added.

> 
> > -static int local_utimensat(FsContext *s, const char *path,
> > -                           const struct timespec *buf)
> > +static int local_utimensat(FsContext *fs_ctx, const char *path,
> > +                const struct timespec *buf)
> >  {
> > -    return qemu_utimensat(AT_FDCWD, rpath(s, path), buf,
> > AT_SYMLINK_NOFOLLOW); +    if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
> > +        int fd, retval;
> > +        fd = passthrough_open(fs_ctx, path, O_RDONLY | O_NONBLOCK);
> 
> This follows symlinks but the SM_PASSTHROUGH case below does not?
Will fix.
> 
> > +        if (fd < 0) {
> > +            return -1;
> > +        }
> > +        retval = futimens(fd, buf);
> > +        close(fd);
> > +        return retval;
> > +    } else {
> > +        return utimensat(AT_FDCWD, rpath(fs_ctx, path), buf,
> > +                        AT_SYMLINK_NOFOLLOW);
> > +    }
> >  }
> > 
> > -static int local_remove(FsContext *ctx, const char *path)
> > -{
> > -    return remove(rpath(ctx, path));
> > +static int local_remove(FsContext *fs_ctx, const char *path)
> > + {
> > +    if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
> > +        int pfd, err, serrno, flags;
> > +        char *old_path;
> > +        struct stat stbuf;
> > +        pfd = get_dirfd(fs_ctx, path);
> > +        if (pfd < 0) {
> > +            return -1;
> > +        }
> > +        old_path = qemu_strdup(path);
> > +        err = fstatat(pfd, basename(old_path), &stbuf,
> > AT_SYMLINK_NOFOLLOW); +        if (err < 0) {
> 
> old_path and pfd are leaked.
> 
> > +            return -1;
> > +        }
> > +        serrno = flags = 0;
> > +        if ((stbuf.st_mode & S_IFMT) == S_IFDIR) {
> > +            flags = AT_REMOVEDIR;
> > +        } else {
> > +            flags = 0;
> > +        }
> > +        err = unlinkat(pfd, basename(old_path), flags);
> > +        if (err == -1) {
> > +            serrno = errno;
> > +        }
> > +        qemu_free(old_path);
> > +        close(pfd);
> > +        errno = serrno;
> > +        return err;
> 
> Why is SM_PASSTHROUGH so complicated...
> 
> > +    } else {
> > +        return remove(rpath(fs_ctx, path));
> 
> ...but this so simple?
> 
> Could we just send a remove operation to the chroot worker instead?
> 

 

----
M. Mohan Kumar

  reply	other threads:[~2011-03-09  8:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-04  9:25 [Qemu-devel] [V7 PATCH 0/9] virtio-9p: Use chroot to safely access files in passthrough security model M. Mohan Kumar
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 1/9] Implement qemu_read_full M. Mohan Kumar
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 2/9] virtio-9p: Enable CONFIG_THREAD if CONFIG_VIRTFS is enabled M. Mohan Kumar
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 3/9] virtio-9p: Provide chroot worker side interfaces M. Mohan Kumar
2011-03-04 10:53   ` [Qemu-devel] " Stefan Hajnoczi
2011-03-08  5:10     ` Venkateswararao Jujjuri (JV)
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 4/9] virtio-9p: Add qemu side interfaces for chroot environment M. Mohan Kumar
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 5/9] virtio-9p: Add support to open a file in " M. Mohan Kumar
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 6/9] virtio-9p: Create support " M. Mohan Kumar
2011-03-04 10:28   ` [Qemu-devel] " Stefan Hajnoczi
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 7/9] virtio-9p: Support for creating special files M. Mohan Kumar
2011-03-04 11:06   ` [Qemu-devel] " Stefan Hajnoczi
2011-03-09  8:08     ` M. Mohan Kumar
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 8/9] virtio-9p: Move file post creation changes to none security model M. Mohan Kumar
2011-03-04  9:25 ` [Qemu-devel] [V7 PATCH 9/9] virtio-9p: Chroot environment for other functions M. Mohan Kumar
2011-03-04 11:52   ` [Qemu-devel] " Stefan Hajnoczi
2011-03-09  8:10     ` M. Mohan Kumar [this message]
2011-03-11 17:12   ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201103091340.53088.mohan@in.ibm.com \
    --to=mohan@in.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).