on 01/06/2013 17:07, Alon Bar-Lev wrote:
----- Original Message -----
From: "Zhou Zheng Sheng" zhshzhou@linux.vnet.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Sunday, January 6, 2013 11:03:59 AM Subject: Re: [vdsm] starting up vdsm and svdsm I think splitting VDSM and super VDSM into two services and delegate everything to systemd is simple and robust, just like libvirtd and VDSM. The auth key problem you mentioned also applies to connecting libvirtd, we can just follow the existing solution for it.
I don't understand this auth key thing. Why is it required? Shouldn't it be sufficient to allow only vdsm user to interact with svdsm?
Thanks, Alon.
The auth key is not very useful. It is passed in the command arguments of super VDSM server, very insecure.
By writing follow the existing solution, I mean libvirtd refer to a SASL DB for password and VDSM refer to /etc/pki/vdsm/keys/libvirt_password when connecting to libvirtd.
I agree to allow only vdsm user to access the svdsm.sock and forget the auth key thing because saving the auth key in a vdsm user readonly file does not improve any security level. If the some one can access svdsm.sock, he can always access libvirt_password. libvirtd is mean to be used by many clients so its unix socket file can not be restricted to vdsm user only, it needs a password for each user in the SASL DB. The super VDSM server is only for VDSM itself, so restricting access svdsm.sock is enough, no auth key needed.