SASL Auth seems to be ineffective

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Rebuild RPM with --enable-sasl and install.
2.  Run memcached with /usr/bin/memcached -u nobody -v -m 128 -p 11211 -S -d -vv
3.  Install ruby and the dalli gem (gem install dalli)
4.  run irb and give it the following input (make sure that the 
username/password are invalid):

require 'dalli'
options = { :namespace => "tspencertest", :compress => true, :username => 
"foo", :password => "XXX" }
dc = Dalli::Client.new('localhost:11211', options)
dc.set('aaa',123)
dc.set('aaa',123)

What is the expected output? What do you see instead?

The first dc.set fails because of SASL:
2.0.0p353 :004 > dc.set('aaa',123)
I, [2014-04-23T00:21:34.194954 #8913]  INFO -- : Dalli/SASL authenticating as 
foo
Dalli::DalliError: Error authenticating: 32
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/server.rb:686:in `sasl_authentication'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/server.rb:558:in `connect'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/server.rb:87:in `alive?'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/options.rb:24:in `block in alive?'
    from /usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/options.rb:23:in `alive?'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/ring.rb:42:in `server_for_key'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/client.rb:322:in `perform'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/dalli-2.7.0/lib/dalli/client.rb:103:in `set'
    from (irb):4
    from /usr/local/rvm/rubies/ruby-2.0.0-p353/bin/irb:12:in `<main>'
2.0.0p353 :005 > 

Which is proper.  But if you do the set (or get, or anything, for that matter) 
again, it works:

2.0.0p353 :005 > dc.set('aaa',123)
 => 792633534417207296 
2.0.0p353 :006 > 

I would expect it to continue to deny us access until we reconnected with 
proper credentials.  If you do give proper credentials, it works properly (no 
exceptions).

What version of the product are you using? On what operating system?

1.4.15, compiled from source using the specfile in the tarball (plus 
--enable-sasl), on CentOS 6.3.

Please provide any additional information below.

Here is debug info spit out from the -vv for the dalli session above:

<28 new binary client connection.
28: going from conn_new_cmd to conn_waiting
28: going from conn_waiting to conn_read
28: going from conn_read to conn_parse_cmd
<28 Read binary protocol data:
<28    0x80 0x0b 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
authenticated() in cmd 0x0b is true
>28 Writing bin response:
>28   0x81 0x0b 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x06
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
28: going from conn_parse_cmd to conn_mwrite
28: going from conn_mwrite to conn_new_cmd
28: going from conn_new_cmd to conn_waiting
28: going from conn_waiting to conn_read
28: going from conn_read to conn_parse_cmd
<28 Read binary protocol data:
<28    0x80 0x20 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
authenticated() in cmd 0x20 is true
>28 Writing bin response:
>28   0x81 0x20 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x05
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
28: going from conn_parse_cmd to conn_mwrite
28: going from conn_mwrite to conn_new_cmd
28: going from conn_new_cmd to conn_waiting
28: going from conn_waiting to conn_read
28: going from conn_read to conn_parse_cmd
<28 Read binary protocol data:
<28    0x80 0x21 0x00 0x05
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x0d
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
authenticated() in cmd 0x21 is true
28: going from conn_parse_cmd to conn_nread
mech:  ``PLAIN'' with 8 bytes of data
SASL (severity 2): Password verification failed
sasl result code:  -20
Unknown sasl response:  -20
>28 Writing an error: Auth failure.
>28 Writing bin response:
>28   0x81 0x21 0x00 0x00
>28   0x00 0x00 0x00 0x20
>28   0x00 0x00 0x00 0x0d
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
28: going from conn_nread to conn_mwrite
28: going from conn_mwrite to conn_new_cmd
28: going from conn_new_cmd to conn_waiting
28: going from conn_waiting to conn_read
28: going from conn_read to conn_parse_cmd
<28 Read binary protocol data:
<28    0x80 0x01 0x00 0x10
<28    0x08 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x1d
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
<28    0x00 0x00 0x00 0x00
authenticated() in cmd 0x01 is true
28: going from conn_parse_cmd to conn_nread
<28 SET tspencertest:aaa Value len is 5
> FOUND KEY tspencertest:aaau 1 5
i{

>28 Writing bin response:
>28   0x81 0x01 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x00
>28   0x00 0x00 0x00 0x0b
28: going from conn_nread to conn_mwrite
28: going from conn_mwrite to conn_new_cmd
28: going from conn_new_cmd to conn_waiting
28: going from conn_waiting to conn_read

My theory is that you guys were expecting people to disconnect after getting a 
bad auth, but dalli is not, and somehow that results in an authenticated binary 
session?  Dunno.

Anyways, if you can help me out here, it would make me very happy.  Thanks, and 
have fun!

Original issue reported on code.google.com by timdavid...@gmail.com on 23 Apr 2014 at 12:29

[GoogleCodeExporter]

hey! I have a stupid question:

Did you miss the .16, .17 releases somehow? This was fixed already. Where were 
you looking for the latest release? Can you try against the latest versions? 
They go all the way to .18!

Original comment by dorma...@rydia.net on 23 Apr 2014 at 12:31

[GoogleCodeExporter]

Oh, wups.  You will also want to make sure that SASL auth is set up properly 
before starting memcached up.  For me, that was:

1) I added a few users to make sure that /etc/sasldb2 was set up:

saslpasswd2 -c -a memcached asdf

2) chmod 644 /etc/sasldb2
3) /etc/sasl2/memcached.conf set up with this:

mech_list: plain cram-md5
log_level: 5

I think that should do it.  I'm sure you know this, but who knows, maybe 
cram-md5 is the culprit.  Many examples seem to just use PLAIN.

Original comment by timdavid...@gmail.com on 23 Apr 2014 at 12:49

[GoogleCodeExporter]

Well yes, but it was definitely broken in .15.

going to close this out.

Original comment by dorma...@rydia.net on 23 Apr 2014 at 12:53

• Changed state: Invalid

[GoogleCodeExporter]

Hey, just saw your response.  I downloaded the tarball from 
https://code.google.com/p/memcached/downloads/list, where it was the latest and 
greatest.  I also didn't find any SASL related issues like this one in this 
issue system, so I figured that it was new.

But now I found memcached.org, and sure enough, there is newer stuff.  I'll try 
it out.  Thanks!

Original comment by timdavid...@gmail.com on 23 Apr 2014 at 12:55

[GoogleCodeExporter]

google code froze project uploads... I have a note to redo the download page 
and redirect it, but haven't done so yet.

seems like I need to do that tonight.

Original comment by dorma...@rydia.net on 23 Apr 2014 at 12:59