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: [V6 PATCH 5/9] virtio-9p: Add support to open a file in chroot environment
Date: Thu, 3 Mar 2011 19:24:42 +0530	[thread overview]
Message-ID: <201103031924.43255.mohan@in.ibm.com> (raw)
In-Reply-To: <AANLkTik_crHChwGgmTa6X6gBRPBq2d2wSTAUocnvqMTf@mail.gmail.com>

On Thursday 03 March 2011 5:39:55 pm Stefan Hajnoczi wrote:
> > +    v9fs_write_request(fs_ctx->chroot_socket, request);
> > +    fd = v9fs_receivefd(fs_ctx->chroot_socket, &sock_error);
> > +    if (fd < 0 && sock_error) {
> > +        fs_ctx->chroot_ioerror = 1;
> > +    }
> 
> chroot_ioerror, sock_error, and their FdInfo bits are redundant code.
> The chroot child could just exit on error and the parent would get
> errors when writing the request here, which is the same effect as
> manually returning -EIO in this function.  There is no need to
> introduce variables and bits to communicate this failure mode.
> 
> Once that simplification has been made, FdInfo becomes just an -errno
> value to pass back the result of open(2) and friends.  That means we
> can completely drop FdInfo and the fi_fd field which doesn't actually
> hold a useful fd value for the QEMU process but just a -errno.
>

But we need to pass the fd to qemu process,  so it could not be -errno. When 
fd >= 0 its a valid fd otherwise its a errno.

> Instead send back only an int -errno return code from the chroot child.
> 
> You mentioned wanting to distinguish between socket errors and
> blocking syscall errors but since there isn't any real error handling
> that makes use of that information (and I'm not sure there is a good
> error handling strategy that could be used), this is all just adding
> complexity.
> 
> > +/* Helper routine to fill V9fsFileObjectRequest structure */
> > +static int fill_fileobjectrequest(V9fsFileObjectRequest *request,
> > +                const char *path, FsCred *credp)
> > +{
> > +    if (strlen(path) > PATH_MAX) {
> > +        return -ENAMETOOLONG;
> > +    }
> 
> Off-by-one error.  It should strlen(path) >= PATH_MAX to account for
> the NUL terminator.
> 
Ok, I Will change!

> > +    memset(request, 0, sizeof(*request));
> > +    request->data.path_len = strlen(path);
> > +    strcpy(request->path.path, path);
> > +    if (credp) {
> > +        request->data.mode = credp->fc_mode;
> > +        request->data.uid = credp->fc_uid;
> > +        request->data.gid = credp->fc_gid;
> > +        request->data.dev = credp->fc_rdev;
> > +    }
> > +    return 0;
> > +}
> > +
> > +static int passthrough_open(FsContext *fs_ctx, const char *path, int
> > flags) +{
> > +    V9fsFileObjectRequest request;
> > +    int fd;
> > +
> > +    fd = fill_fileobjectrequest(&request, path, NULL);
> > +    if (fd < 0) {
> > +        errno = -fd;
> 
> Please don't use errno to communicate errors back.  In this function
> it would be perfectly fine to return fd here since it is already a
> -errno.
> 
> It's not safe to use errno since it's value can be lost by calling any
> external function - its value may be modified even if no error occurs.
>  I quoted from the errno(3) man page in a previous review:
> "a function that succeeds *is* allowed to change errno"
> 
> > +        return -1;
> > +    }
> > +    request.data.flags = flags;
> > +    request.data.type = T_OPEN;
> > +    fd = v9fs_request(fs_ctx, &request);
> > +    return fd;
> > +}
> > 
> >  static int local_lstat(FsContext *fs_ctx, const char *path, struct stat
> > *stbuf) {
> > @@ -138,14 +175,27 @@ static int local_closedir(FsContext *ctx, DIR *dir)
> >     return closedir(dir);
> >  }
> > 
> > -static int local_open(FsContext *ctx, const char *path, int flags)
> > +static int local_open(FsContext *fs_ctx, const char *path, int flags)
> >  {
> > -    return open(rpath(ctx, path), flags);
> > +    if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
> > +        return passthrough_open(fs_ctx, path, flags);
> > +    } else {
> > +        return open(rpath(fs_ctx, path), flags);
> > +    }
> >  }
> > 
> > -static DIR *local_opendir(FsContext *ctx, const char *path)
> > +static DIR *local_opendir(FsContext *fs_ctx, const char *path)
> >  {
> > -    return opendir(rpath(ctx, path));
> > +    if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
> > +        int fd;
> > +        fd = passthrough_open(fs_ctx, path, O_DIRECTORY);
> > +        if (fd < 0) {
> > +            return NULL;
> > +        }
> > +        return fdopendir(fd);
> > +    } else {
> > +        return opendir(rpath(fs_ctx, path));
> > +    }
> 
> Perhaps we should use a local_operations struct or similar function
> pointer table instead of adding fs_ctx->fs_sm conditionals everywhere.

That would have more code duplication when compared to additional 
conditionals. i.e, We need to create local_passthrough_opendir, 
local_passthrough_open, .. etc.
 
> 
> Also it would be neat to reuse the local implementations on the chroot
> child side instead of instead of splitting code paths, but I'm not
> sure whether that is possible.
I am not sure what do you mean by reusing the virtio-9p-local.c implementation 
in chilld side. That may involve breaking down existing  local functions?

----
M. Mohan Kumar

  reply	other threads:[~2011-03-03 14:56 UTC|newest]

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

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=201103031924.43255.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).