qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "M. Mohan Kumar" <mohan@in.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [V3 PATCH 7/8] virtio-9p: Move file post creation changes to none security model
Date: Thu, 20 Jan 2011 22:55:42 -0800	[thread overview]
Message-ID: <4D392DEE.7070003@linux.vnet.ibm.com> (raw)
In-Reply-To: <AANLkTini7+aZcUFHcfDd709FosNbw5L9sX6Nq_hxoHyh@mail.gmail.com>

On 1/20/2011 1:45 PM, Stefan Hajnoczi wrote:
> On Thu, Jan 20, 2011 at 9:15 PM, Venkateswararao Jujjuri (JV)
> <jvrao@linux.vnet.ibm.com> wrote:
>> On 1/20/2011 12:59 AM, Stefan Hajnoczi wrote:
>>> On Tue, Jan 18, 2011 at 01:54:16PM +0530, M. Mohan Kumar wrote:
>>>> After creating a file object, its permission and ownership details are updated
>>>> as per client's request for both passthrough and none security model. But with
>>>> chrooted environment its not required for passthrough security model. Move all
>>>> post file creation changes to none security model
>>>>
>>>> Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
>>>> ---
>>>>  hw/9pfs/virtio-9p-local.c |   19 ++++++-------------
>>>>  1 files changed, 6 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
>>>> index 08fd67f..d2e32e2 100644
>>>> --- a/hw/9pfs/virtio-9p-local.c
>>>> +++ b/hw/9pfs/virtio-9p-local.c
>>>> @@ -208,21 +208,14 @@ static int local_set_xattr(const char *path, FsCred *credp)
>>>>      return 0;
>>>>  }
>>>>
>>>> -static int local_post_create_passthrough(FsContext *fs_ctx, const char *path,
>>>> +static int local_post_create_none(FsContext *fs_ctx, const char *path,
>>>>          FsCred *credp)
>>>>  {
>>>> +    int retval;
>>>>      if (chmod(rpath(fs_ctx, path), credp->fc_mode & 07777) < 0) {
>>>>          return -1;
>>>>      }
>>>> -    if (lchown(rpath(fs_ctx, path), credp->fc_uid, credp->fc_gid) < 0) {
>>>> -        /*
>>>> -         * If we fail to change ownership and if we are
>>>> -         * using security model none. Ignore the error
>>>> -         */
>>>> -        if (fs_ctx->fs_sm != SM_NONE) {
>>>> -            return -1;
>>>> -        }
>>>> -    }
>>>> +    retval = lchown(rpath(fs_ctx, path), credp->fc_uid, credp->fc_gid);
>>>>      return 0;
>>>>  }
>>>
>>> retval is unused.
>>>
>>> Can multiple virtio-9p requests execute at a time?  chmod() and lchown()
>>> after creation is a race condition if other requests can execute
>>> concurrently.
>>
>> If some level of serialization is needed it will be done at the client/guest
>> inode level.
>> Are you worried about filesystem semantics? or do you see some corruption if they
>> get executed in parallel?
> 
> My main concern is unreliable results due to the race conditions
> between creation and the fixups that are performed afterwards.
> 
> Is virtio-9p only useful for single guest exclusive access?  I thought
> both guest and host could access files at the same time?  What about
> multiple VMs sharing a directory?  These scenarios can only work if
> operations are made atomic.

For now, there is only one exploiter for the filesystem. The Guest/client.

In the future it could be different and we 'may' support multiple exploiters/users.
Note that we have two security models
1. Passthrough 2. Mapped. (3. None -  can be ignored as it is intended for
developer)

Mapped model is advised when you have only one exploiter;
Passthrough model is for more practical application/uses and it can be
used for multiple exploiters (say guests).

In passthrough model we don't do chmod() lchmod() after creating files.

Thanks,
JV
> 
> Stefan

      reply	other threads:[~2011-01-21  6:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-18  6:23 [Qemu-devel] [V3 PATCH 0/8] virtio-9p: Use chroot to safely access files in passthrough model M. Mohan Kumar
2011-01-18  6:25 ` [Qemu-devel] [V3 PATCH 1/8] virtio-9p: Implement qemu_read_full M. Mohan Kumar
2011-01-18  6:25 ` [Qemu-devel] [V3 PATCH 2/8] virtio-9p: Provide chroot environment server side interfaces M. Mohan Kumar
2011-01-18 17:03   ` Blue Swirl
2011-01-18  6:25 ` [Qemu-devel] [V3 PATCH 3/8] virtio-9p: Add client side interfaces for chroot environment M. Mohan Kumar
2011-01-18  6:25 ` [Qemu-devel] [V3 PATCH 4/8] virtio-9p: Add support to open a file in " M. Mohan Kumar
2011-01-18  6:25 ` [Qemu-devel] [V3 PATCH 5/8] virtio-9p: Create support " M. Mohan Kumar
2011-01-18 17:08   ` Blue Swirl
2011-01-19 11:08     ` M. Mohan Kumar
2011-01-18  6:26 ` [Qemu-devel] [V3 PATCH 6/8] virtio-9p: Support for creating special files M. Mohan Kumar
2011-01-18 17:11   ` Blue Swirl
2011-01-18  6:26 ` [Qemu-devel] [V3 PATCH 8/8] virtio-9p: Chroot environment for other functions M. Mohan Kumar
2011-01-18  8:24 ` [Qemu-devel] [V3 PATCH 7/8] virtio-9p: Move file post creation changes to none security model M. Mohan Kumar
2011-01-20  8:59   ` Stefan Hajnoczi
2011-01-20 14:41     ` M. Mohan Kumar
2011-01-20 14:48       ` Daniel P. Berrange
2011-01-20 21:15         ` Stefan Hajnoczi
2011-01-20 21:15     ` Venkateswararao Jujjuri (JV)
2011-01-20 21:45       ` Stefan Hajnoczi
2011-01-21  6:55         ` Venkateswararao Jujjuri (JV) [this message]

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=4D392DEE.7070003@linux.vnet.ibm.com \
    --to=jvrao@linux.vnet.ibm.com \
    --cc=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).