patches posted.

After change the permissions of /etc/qemu/passwd.db and /etc/sasl2/qemu-kvm.conf, I can connect guest with SASL by using PLAIN authentication.

But found the auth was "none" in hmp, seems vnc not.

(qemu) info spice
Server:
     migrated: false
     address: 0.0.0.0:5900
        auth: none
Channels: none

{"execute":"query-spice"}
{"return": {"migrated": false, "enabled": true, "auth": "none", "port": 5900, "host": "0.0.0.0", "channels": []}}

(qemu) info vnc
Server:
     address: 0.0.0.0:5900
        auth: sasl
Client: none

> But found the auth was "none" in hmp, seems vnc not.
> 
> (qemu) info spice
> Server:
>      migrated: false
>      address: 0.0.0.0:5900
>         auth: none
> Channels: none

That is a bug in info spice, sasl is actually active.

Question: Is it a valid use case to have both sasl and spice (ticket) auth active?

Ticket will be ignored when SASL is active.

Ok, so the 'disable-ticketing' on the command line is not needed and has no effect, correct?

And we have these three auth methods:

  if (sasl == on) {
      use sasl
  } else if (disable-ticketing) {
      no auth
  } else {
      classic spice ticket auth
  }

correct?

(In reply to Gerd Hoffmann from comment #12)
> Ok, so the 'disable-ticketing' on the command line is not needed and has no
> effect, correct?
> 
> And we have these three auth methods:
> 
>   if (sasl == on) {
>       use sasl
>   } else if (disable-ticketing) {
>       no auth
>   } else {
>       classic spice ticket auth
>   }
> 
> correct?


disable-ticketing is handled the same as classic spice ticket auth iirc, except that the password is empty.

/me is confused.

So we have these four cases:

(1) -spice $args,password=$secret
    => classic spice ticket auth, with the password being passed
       to spice server using spice_server_set_ticket().

(2) -spice $args,disable-ticketing
    => no auth required to connect

(3) -spice $args,sasl=on,password=$secret
    => authentication via sasl I guess?  Has the password set via 
       spice_server_set_ticket() any effect?  Probably not as sasl
       handles auth?  Should qemu throw an error in case someone
       tries to set a password (via cmd line or monitor) with sasl
       being active?

(4) -spice $args sasl=on,disable-ticketing
    [ In that case qemu calls spice_server_set_sasl(1) first,
      then spice_server_set_noauth() ]
    What is the expected behavior?  Same as (3)?  Or something else?

Please clarify.

An error could be thrown in 3) in order to make it clear to the user that their password is going to be ignored. 'disable-ticketing' is only taken into account when sasl is not used (in which case we fallback to ticketing), so 4) is about the same as 3).

Fix included in qemu-kvm-0.12.1.2-2.425.el6

Test this bug qemu-kvm-0.12.1.2-2.428.el6.x86_64, sasl works well both withe plain auth and ssl.

Host:
qemu-kvm-0.12.1.2-2.428.el6.x86_64

Client:
virt-viewer-0.6.0-9.el6.x86_64

Plain authentication.
1. Set root's sasl password.
# saslpasswd2 -f /etc/qemu/passwd.db root
Password:                           <--- enter password "12345678"
Again (for verification):

# sasldblistusers2 /etc/qemu/passwd.db 
mazhang@dell-per720-02.qe.lab.eng.nay.redhat.com: userPassword
redhat@dell-per720-02.qe.lab.eng.nay.redhat.com: userPassword
rh@dell-per720-02.qe.lab.eng.nay.redhat.com: userPassword
root@dell-per720-02.qe.lab.eng.nay.redhat.com: userPassword

2. Change the permission of /etc/qemu/passwd.db.

3. Boot vm with sasl enabled and ticket disabled.
...
-vga qxl \
-spice port=5900,sasl,disable-ticketing \

4. Connect to guest.
remote-viewer spice://dell-per720-02.qe.lab.eng.nay.redhat.com:5900

5. Enter password login guest.

With SSL certification.
1. Generate certificate file on host.

2. Copy certificate file to client.

3. Boot vm with encrypted channels.
-spice port=5900,sasl=on,tls-port=5910,x509-dir=/home/x509,disable-ticketing

4. Connect to guest.
remote-viewer spice://dell-per720-02.qe.lab.eng.nay.redhat.com?tls-port=5910 --spice-ca-file=/etc/pki/CA/ca-cert.pem

5. Enter password login guest.


But found two problems in my test.
1. Output auth is wrong by "info spice", see comment#9.
2. Boot with "-spice port=5900,disable-ticketing,sasl", and connect to guest.
   Connection will break when "set_password" in hmp monitor.

Gerd, may I file two bugs against above problems?

Thanks,
Mazhang.

> But found two problems in my test.
> 1. Output auth is wrong by "info spice", see comment#9.

IIRC there is a bug for that already.

> 2. Boot with "-spice port=5900,disable-ticketing,sasl", and connect to guest.
>    Connection will break when "set_password" in hmp monitor.

Yes, new bug please.  set_password should throw an error in case sasl is enabled.

(In reply to Gerd Hoffmann from comment #19)
> > But found two problems in my test.
> > 1. Output auth is wrong by "info spice", see comment#9.
> 
> IIRC there is a bug for that already.
> 
Didn't found the bug, could you help paste it here, in case qe miss it.

> > 2. Boot with "-spice port=5900,disable-ticketing,sasl", and connect to guest.
> >    Connection will break when "set_password" in hmp monitor.
> 
> Yes, new bug please.  set_password should throw an error in case sasl is
> enabled.

Has been filed a bug 1115237 against this problem.

Thanks,
Mazhang.

> > > 1. Output auth is wrong by "info spice", see comment#9.
> > 
> > IIRC there is a bug for that already.
> > 
> Didn't found the bug, could you help paste it here, in case qe miss it.

Can't find it either.  Hmm.  Guess we need a new one then.

(In reply to Gerd Hoffmann from comment #21)
> > > > 1. Output auth is wrong by "info spice", see comment#9.
> > > 
> > > IIRC there is a bug for that already.
> > > 
> > Didn't found the bug, could you help paste it here, in case qe miss it.
> 
> Can't find it either.  Hmm.  Guess we need a new one then.

1. Filed a new bug 1115291 against this problem.

2. According to comment#18 comment#19 and comment#20 set this bug verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1490.html