From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=48685 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PxvIy-0002T0-T8
	for qemu-devel@nongnu.org; Fri, 11 Mar 2011 00:54:31 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jvrao@linux.vnet.ibm.com>) id 1PxvIx-000515-Rs
	for qemu-devel@nongnu.org; Fri, 11 Mar 2011 00:54:28 -0500
Received: from e6.ny.us.ibm.com ([32.97.182.146]:43980)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jvrao@linux.vnet.ibm.com>) id 1PxvIx-00050l-PV
	for qemu-devel@nongnu.org; Fri, 11 Mar 2011 00:54:27 -0500
Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56])
	by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2B5U7Mh023911
	for <qemu-devel@nongnu.org>; Fri, 11 Mar 2011 00:30:07 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 39BE838C8039
	for <qemu-devel@nongnu.org>; Fri, 11 Mar 2011 00:54:21 -0500 (EST)
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	p2B5sNMH397340
	for <qemu-devel@nongnu.org>; Fri, 11 Mar 2011 00:54:23 -0500
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id p2B5sMYO011333
	for <qemu-devel@nongnu.org>; Thu, 10 Mar 2011 22:54:23 -0700
Message-ID: <4D79B90A.2020204@linux.vnet.ibm.com>
Date: Thu, 10 Mar 2011 21:54:18 -0800
From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [V8 PATCH 11/11] virtio-9p: Chroot environment
	for other functions
References: <1299690960-12007-1-git-send-email-mohan@in.ibm.com>
	<1299690960-12007-12-git-send-email-mohan@in.ibm.com>
	<AANLkTina-SNs6AKC_y6H=6qWiyX9=ruREJw3L3Z4bYp6@mail.gmail.com>
In-Reply-To: <AANLkTina-SNs6AKC_y6H=6qWiyX9=ruREJw3L3Z4bYp6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "M. Mohan Kumar" <mohan@in.ibm.com>, qemu-devel@nongnu.org

On 3/10/2011 4:29 AM, Stefan Hajnoczi wrote:
> On Wed, Mar 9, 2011 at 5:16 PM, M. Mohan Kumar <mohan@in.ibm.com> wrote:
>> Add chroot functionality for systemcalls that can operate on a file
>> using relative directory file descriptor.
> 
> I suspect the relative directory approach is broken and escapes the
> chroot.  Here's why:
> 
> The request is local_chmod(fs_ctx, "/..", credp).  dirname("/..") is
> "/" and basename("..") is "..".

We should never receive protocol operations with relative path.
Client should always resolve to full path and send the request.
If the client is malicious this scenario can be be possible.. but in that case
it is fine to fail the operation.

Thanks,
JV

> I'm not 100% sure of the semantics but I suspect that chmodat(dir_fd,
> "..", ...) does not honor the chroot since your current task is not
> inside the chroot.  If so, then you can manipulate the parent
> directory of the chroot using some of the operations added in this
> patch.
> 
> The safe solution is to perform all operations inside the chroot.
> This will require extending the chroot socket protocol.
> 
> Stefan
>