Bug 92918

Summary: Use correct SASL service name
Product: Spice Reporter: Marek Kasik <mkasik>
Component: serverAssignee: Spice Bug List <spice-bugs>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: medium CC: teuf
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Use correct SASL service name
Use correct SASL service name - spice-gtk

Description Marek Kasik 2015-11-12 14:18:17 UTC
Created attachment 119591 [details] [review]
Use correct SASL service name

I've been testing GSSAPI authentication of Spice and there seems to be a problem with service name used by Spice. It uses "spice" but there is no "spice" SASL service defined (at least on my Fedora 23 machine). However, there is "qemu" service which is also used on this page http://www.spice-space.org/page/Features/SASL (the /etc/sasl2/qemu.conf part).

I think that until there is no "spice" SASL service defined for Spice you should use the "qemu" SASL service which works for me (even without SSL). Or you can use the "libvirt" SASL service which also works for me.

Regards

Marek
Comment 1 Marek Kasik 2015-11-12 14:18:47 UTC
Created attachment 119592 [details] [review]
Use correct SASL service name - spice-gtk
Comment 2 Marc-Andre Lureau 2015-11-12 14:30:31 UTC
The server uses "spice" too. Imho, it's better to ship a "spice" sasl service configuration with the server.
Comment 3 Marc-Andre Lureau 2015-11-12 14:31:47 UTC
beside, spice can be used without qemu, so it sounds wrong to depend on qemu sasl configuration here.
Comment 4 Marek Kasik 2015-11-12 14:39:28 UTC
(In reply to Marc-Andre Lureau from comment #3)
> beside, spice can be used without qemu, so it sounds wrong to depend on qemu
> sasl configuration here.

I'm happy with whatever will work :). Thanks
Comment 5 Marc-Andre Lureau 2015-11-12 14:42:01 UTC
(In reply to Marek Kasik from comment #4)
> I'm happy with whatever will work :). Thanks

Please check if a spice.conf file similar to qemu.conf would work. If yes, send a patch to spice ML.
Comment 6 Marek Kasik 2015-11-12 14:48:46 UTC
(In reply to Marc-Andre Lureau from comment #5)
> (In reply to Marek Kasik from comment #4)
> > I'm happy with whatever will work :). Thanks
> 
> Please check if a spice.conf file similar to qemu.conf would work. If yes,
> send a patch to spice ML.

I've actually tried this but it didn't work for me. I'll try it again.
Comment 7 Christophe Fergeau 2015-11-16 12:27:53 UTC
When QEMU is used, the server ends up using /etc/sasl2/qemu.conf because QEMU is calling
spice_server_set_sasl_appname(spice_server, "qemu");
which will cause spice-server to call
sasl_server_init(NULL, "qemu");
rather than the default
sasl_server_init(NULL, "spice");

I'm not sure what SASL does with the service name passed to sasl_{server,client}_new() though. This one is always "spice" both server-side and client-side.

http://www.sendmail.org/~ca/email/cyrus2/programming.html#sasl_server_new indicates that « [The name of the service] is used by Kerberos mechanisms and possibly other mechanisms. It is also used for PAM authentication », but I don't know exactly how. If it uses this to locate configuration files, strace -e open should tell us.
Comment 8 Marek Kasik 2015-11-18 11:07:29 UTC
(In reply to Christophe Fergeau from comment #7)
> When QEMU is used, the server ends up using /etc/sasl2/qemu.conf because
> QEMU is calling
> spice_server_set_sasl_appname(spice_server, "qemu");
> which will cause spice-server to call
> sasl_server_init(NULL, "qemu");
> rather than the default
> sasl_server_init(NULL, "spice");
> 
> I'm not sure what SASL does with the service name passed to
> sasl_{server,client}_new() though. This one is always "spice" both
> server-side and client-side.
> 
> http://www.sendmail.org/~ca/email/cyrus2/programming.html#sasl_server_new
> indicates that « [The name of the service] is used by Kerberos mechanisms
> and possibly other mechanisms. It is also used for PAM authentication », but
> I don't know exactly how. If it uses this to locate configuration files,
> strace -e open should tell us.

Thank you for pointing me there. SASL creates the path to the configuration file from the "appname" passed to it which is "qemu" when running qemu (see https://cgit.cyrus.foundation/cyrus-sasl/tree/lib/server.c#n653). stracing qemu shows that it really opened the /etc/sasl2/qemu.conf instead of the /etc/sasl2/spice.conf so it could not find the correct keytab file. Not allowing the application to initialize the "appname" makes the authentication working.
(I'm not sure why the libvirt worked for me before - probably the same keytab...)

So what is the right way to make this work?
Should we disable usage of the appname passed by "spice_server_set_sasl_appname()" in spice server or don't set it in qemu?
Comment 9 Christophe Fergeau 2015-11-18 11:16:45 UTC
(In reply to Marek Kasik from comment #8)
> Thank you for pointing me there. SASL creates the path to the configuration
> file from the "appname" passed to it which is "qemu" when running qemu (see
> https://cgit.cyrus.foundation/cyrus-sasl/tree/lib/server.c#n653). stracing
> qemu shows that it really opened the /etc/sasl2/qemu.conf instead of the
> /etc/sasl2/spice.conf so it could not find the correct keytab file. Not
> allowing the application to initialize the "appname" makes the
> authentication working.

I don't understand what you mean by "it could not find the correct keytab file"? Do you refer to the keytab: /etc/qemu/krb5.tab field in /etc/sasl2/qemu.conf? Is there anything wrong with using this keytab file rather than /etc/spice/something.tab?
Comment 10 Marek Kasik 2015-11-18 11:43:49 UTC
(In reply to Christophe Fergeau from comment #9)
> (In reply to Marek Kasik from comment #8)
> > Thank you for pointing me there. SASL creates the path to the configuration
> > file from the "appname" passed to it which is "qemu" when running qemu (see
> > https://cgit.cyrus.foundation/cyrus-sasl/tree/lib/server.c#n653). stracing
> > qemu shows that it really opened the /etc/sasl2/qemu.conf instead of the
> > /etc/sasl2/spice.conf so it could not find the correct keytab file. Not
> > allowing the application to initialize the "appname" makes the
> > authentication working.
> 
> I don't understand what you mean by "it could not find the correct keytab
> file"? Do you refer to the keytab: /etc/qemu/krb5.tab field in
> /etc/sasl2/qemu.conf?

Yes, I was referring to the line which specifies the keytab file in the sasl service config file. 

> Is there anything wrong with using this keytab file
> rather than /etc/spice/something.tab?

It should be at least possible if we will create the "/etc/sasl2/spice.conf" which can configure the keytab file.

Btw, I used FreeIPA's guide to create the keytab and the command "ipa-getkeytab" doesn't allow me to create keytab with more than 1 principal (see https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Configuring_Service_Principals-Creating_and_Using_Service_Principals.html).
Comment 11 Christophe Fergeau 2015-11-18 12:27:22 UTC
Please bear with me if I'm slow/if I ask basic questions, but I'm very unfamiliar with kerberos/freeipa/..., even "principal" does not mean a lot to me /o\

(In reply to Marek Kasik from comment #10)
> It should be at least possible if we will create the "/etc/sasl2/spice.conf"
> which can configure the keytab file.

Do we _have_ to use a spice.conf file? I think the use of qemu.conf is more or less by design.

> 
> Btw, I used FreeIPA's guide to create the keytab and the command
> "ipa-getkeytab" doesn't allow me to create keytab with more than 1 principal
> (see
> https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/
> Configuring_Service_Principals-Creating_and_Using_Service_Principals.html).

Hmm I guess the crux of it is
« The following example demonstrates creating a service principal and keytab on a client host for the HTTP service. »

« Similar locations can be specified for each service that needs to be made Kerberos aware. [...] each service should have its keytab saved in a specific location and the access privileges (and possibly SELinux rules) should be configured so that only this service has access to the keytab. »

QEMU uses /etc/sasl2/qemu.conf for both the SPICE and VNCC services, so a different keytab file cannot be used for both SPICE and VNC, which is wrong according to the instructions above?
Comment 12 Marek Kasik 2015-11-18 13:36:35 UTC
(In reply to Christophe Fergeau from comment #11)
> Please bear with me if I'm slow/if I ask basic questions, but I'm very
> unfamiliar with kerberos/freeipa/..., even "principal" does not mean a lot
> to me /o\

Sure :)
FreeIPA is a very nice tool which simplifies configuration of combination of LDAP and Kerberos servers from my point of view (it does other things too but I don't use them now). So I can easily add users, hosts and services there. Kerberos calls all of them principals which is a little confusing (correct me somebody if I'm wrong).
To have this working it was enough to run "ipa-server-install", add user "mkasik" with "ipa user-add", add hostname for which I'll request tickets with "ipa host-add", add services for which I need tickets with "ipa service-add" and finally export keytab for the required services. (+ you really need well resolved hostnames and correct permissions on the keytab files!)

> (In reply to Marek Kasik from comment #10)
> > It should be at least possible if we will create the "/etc/sasl2/spice.conf"
> > which can configure the keytab file.
> 
> Do we _have_ to use a spice.conf file? I think the use of qemu.conf is more
> or less by design.

I just tried to make the suggestion from comment #5 working (and #3).


> > Btw, I used FreeIPA's guide to create the keytab and the command
> > "ipa-getkeytab" doesn't allow me to create keytab with more than 1 principal
> > (see
> > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/
> > Configuring_Service_Principals-Creating_and_Using_Service_Principals.html).
> 
> Hmm I guess the crux of it is
> « The following example demonstrates creating a service principal and keytab
> on a client host for the HTTP service. »
> 
> « Similar locations can be specified for each service that needs to be made
> Kerberos aware. [...] each service should have its keytab saved in a
> specific location and the access privileges (and possibly SELinux rules)
> should be configured so that only this service has access to the keytab. »
> 
> QEMU uses /etc/sasl2/qemu.conf for both the SPICE and VNCC services, so a
> different keytab file cannot be used for both SPICE and VNC, which is wrong
> according to the instructions above?

Looking at "https://libvirt.org/auth.html#ACL_server_config" and using kadmin it seems that it is possible to add more principals to one keytab file (and it works).

So, I'm not sure right now whether to add the spice.conf or just use the qemu configuration (the proposed patches).
Comment 13 Marc-Andre Lureau 2015-11-18 13:46:57 UTC
(In reply to Marek Kasik from comment #12)
> So, I'm not sure right now whether to add the spice.conf or just use the
> qemu configuration (the proposed patches).

As Christophe said, qemu.conf should be used by qemu. 

   spice_server_set_sasl_appname() - specify the name of the app (It is
    used for where to find the default configuration file)

Why isn't spice_server_set_sasl_appname(server, "qemu") enough to make it all work? (I know it used to work with digest-md5) iow, why is any of your patch necessary?
Comment 14 Marek Kasik 2015-11-18 14:24:41 UTC
(In reply to Marc-Andre Lureau from comment #13)
> (In reply to Marek Kasik from comment #12)
> > So, I'm not sure right now whether to add the spice.conf or just use the
> > qemu configuration (the proposed patches).
> 
> As Christophe said, qemu.conf should be used by qemu. 
> 
>    spice_server_set_sasl_appname() - specify the name of the app (It is
>     used for where to find the default configuration file)
> 
> Why isn't spice_server_set_sasl_appname(server, "qemu") enough to make it
> all work? (I know it used to work with digest-md5) iow, why is any of your
> patch necessary?

OK, I was wrong. I thought that the config filename has to reflect the service name but it seems that it should reflect the application name. Using qemu.conf and pointing it to a keytab with "spice/the.hostname@THE-REALM.COM" principal works here. So I'm closing this.

Thank you for your help.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.