From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNTaO-0000Vg-0t for qemu-devel@nongnu.org; Mon, 16 Feb 2015 16:52:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNTYJ-0002FT-K1 for qemu-devel@nongnu.org; Mon, 16 Feb 2015 16:50:08 -0500 Received: from e37.co.us.ibm.com ([32.97.110.158]:45025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNTYJ-0002EZ-5y for qemu-devel@nongnu.org; Mon, 16 Feb 2015 16:50:03 -0500 Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 16 Feb 2015 14:50:02 -0700 Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 17E691FF002D for ; Mon, 16 Feb 2015 14:41:11 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t1GLo25T29884470 for ; Mon, 16 Feb 2015 14:50:02 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t1GLnYKY008018 for ; Mon, 16 Feb 2015 14:49:34 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth References: <1423653972-15435-1-git-send-email-berrange@redhat.com> <20150212132108.GA17524@rkaganb.sw.ru> <20150212140556.GK32208@redhat.com> In-Reply-To: <20150212140556.GK32208@redhat.com> Message-ID: <20150216214919.13315.51759@loki> Date: Mon, 16 Feb 2015 15:49:19 -0600 Subject: Re: [Qemu-devel] [PATCH v3] qga: add guest-set-user-password command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Roman Kagan , qemu-devel@nongnu.org, Eric Blake , Olga Krishtal Quoting Daniel P. Berrange (2015-02-12 08:05:56) > On Thu, Feb 12, 2015 at 04:21:09PM +0300, Roman Kagan wrote: > > On Wed, Feb 11, 2015 at 11:26:12AM +0000, Daniel P. Berrange wrote: > > > Add a new 'guest-set-user-password' command for changing the password > > > of guest OS user accounts. This command is needed to enable OpenStack > > > to support its API for changing the admin password of guests running > > > on KVM/QEMU. It is not practical to provide a command at the QEMU > > > level explicitly targetting administrator account password change > > > only, since different guest OS have different names for the admin > > > account. While UNIX systems use 'root', Windows systems typically > > > use 'Administrator' and even that can be renamed. Higher level apps > > > like OpenStack have the ability to figure out the correct admin > > > account name since they have info that QEMU/libvirt do not. > > > = > > > The command accepts either the clear text password string, encoded > > > in base64 to make it 8-bit safe in JSON: > > > = > > > $ echo -n "123456" | base64 > > > MTIzNDU2 > > > $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ > > > '{ "execute": "guest-set-user-password", > > > "arguments": { "crypted": false, > > > "username": "root", > > > "password": "MTIzNDU2" } }' > > > {"return":{}} > > > = > > > Or a password that has already been run though a crypt(3) like > > > algorithm appropriate for the guest, again then base64 encoded: > > > = > > > $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 > > > JDYkb...snip...YT2Ey > > > $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ > > > '{ "execute": "guest-set-user-password", > > > "arguments": { "crypted": true, > > > "username": "root", > > > "password": "JDYkb...snip...YT2Ey" } }' > > > = > > = > > So how would it look like for user "Daniel=C2=A0P.=C2=A0Berrang=C3=A9" = (with accent > > aigu :), or "=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD =D0=9A=D0=B0=D0=B3=D0=B0=D0= =BD" (my name in cyrillic letters)? What I'm > > trying to say is that if we assume localized usernames we may have > > trouble with character encoding. > = > The JSON string typed accepts UTF-8 encoding strings, so you can > have any of those localized names. If the API/command that the > agent invokes doesn't use UTF-8 (unlikely) then the agent would > do a charset conversion as needed. > = > > > + passwd_path =3D g_find_program_in_path("chpasswd"); > > > + > > > + if (!passwd_path) { > > > + error_setg(errp, "cannot find 'passwd' program in PATH"); > > = > > Minor nitpick: s/passwd/chpasswd/ > > = > > The patch looks technically correct; however I'm not sold on the > > approach, which assumes a responsibility split between the upper > > management layer, which is supposed to know the guest OS, the username, > > the encryption scheme, and the guest agent which takes care of the > > os-specific command to actually change the password. I still tend to > > like more the scheme with the management layer having all the necessary > > information, including the command to change the password and the proper > > way to call it, and using guest-exec to perform it. > = > guest-exec is not something that is generally supportable. By virtue > of the fact that it is designed to allow arbitrary command execution, > you can't provide security policy out of the box that confines its > in any meaningfully secure way. By having a dedicated qapi comand for > this, we can write security policy that allows precisely the command > needed, no more, no less. This commands provides a simple mechanism > for the feature, while the user or application can define its policy > for using it. > = > > IMO the question is how low the bar is to extend the qga protocol with > > yet another general-purpose (i.e. not virtual machine-specific) OS > > management task. I'd rather see it out of scope for qga. Instead, such > > an upper management layer, if necessary, would bring its own agent, with > > qga acting as a transport. This way e.g. OpenStack would be able to > > uniformly change admin passwords also in ESXi, Parallels Server, LXC, > > OpenVz, physical servers, etc. > = > This proposed feature is a generally useful for regaining access to a > guest for which you've lost login access. Putting it in an application > specific agent results in every app managing QEMU reinventing the > wheel which is just madness. We've already got QEMU guest agent and > SPICE guest agent, adding a 3rd openstack agent is not a desirable > path to take. For the cross hypervisor portability problem we already > have libvirt, so again pushing it up into openstack just makes life > worse for non-openstack apps which want this. I agree. It's true that we don't want QGA to become too closely tied/integrated with high-level management tasks (since they tend to be very environment/implementation specific), but if a feature proves to be generally useful across the board then a good argument can be made for pushing it down into a lower-level agent like QGA that a simpler "out of the box" solution can potentially benefit from as well: e.g. node-level management like libvirt, kimchi, virt-manager, etc. The interesting stuff like SSO, package-management, etc, is what should be left to a more integrated agent (or the general-purpose/transport aspects of QGA like guest-file-*/guest-exec*). > = > Regards, > Daniel > -- = > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| > |: http://libvirt.org -o- http://virt-manager.or= g :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|