Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 364 by timdavid...@gmail.com: SASL Auth seems to be ineffective
http://code.google.com/p/memcached/issues/detail?id=364
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!
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
---
You received this message because you are subscribed to the Google Groups "memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
