All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.