From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MVX5h-00064C-8E
	for qemu-devel@nongnu.org; Mon, 27 Jul 2009 16:46:37 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MVX5c-00060Q-AX
	for qemu-devel@nongnu.org; Mon, 27 Jul 2009 16:46:36 -0400
Received: from [199.232.76.173] (port=36628 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MVX5b-0005zs-Eb
	for qemu-devel@nongnu.org; Mon, 27 Jul 2009 16:46:31 -0400
Received: from mail2.shareable.org ([80.68.89.115]:41588)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1MVX5a-00068W-VT
	for qemu-devel@nongnu.org; Mon, 27 Jul 2009 16:46:31 -0400
Date: Mon, 27 Jul 2009 21:46:27 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest
	communication
Message-ID: <20090727204627.GA32432@shareable.org>
References: <1248717876-17630-1-git-send-email-amit.shah@redhat.com>
	<4A6E0C9E.10908@codemonkey.ws> <20090727203214.GG15020@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090727203214.GG15020@redhat.com>
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.gnu.org/pipermail/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: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>, virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org, kvm@vger.kernel.org

Daniel P. Berrange wrote:
> > I expect the first problem you'll run into is that copy/paste daemon has 
> > to run as an unprivileged user but /dev/vmch3 is going to be owned by 
> > root.  You could set udev rules for /dev/vmch3 but that's pretty 
> > terrible IMHO.
> 
> I don't think that's not too bad, for example, with fast-user-switching 
> between multiple X servers and/or text consoles, there's already support
> code that deals with chown'ing things like /dev/snd/* devices to match 
> the active console session. Doing the same with the /dev/vmch3 device so
> that it is only ever accessible to the current logged in user actually
> fits in to that scheme quite well.

With multiple X servers, there can be more than one currently logged in user.

Same with multiple text consoles - that's more familiar.

Which one owns /dev/vmch3?

-- Jamie