Major Description
Owing to a misconfiguration at the client where certificate authentication was configured and enabled with an empty certificate list, the client would correctly negotiate TLS and then move directly to a select bucket. When the select bucket command was issued, an EACCESS would be returned to the client as expected, but no additional logging was in memcached.log indicating the connection was not authenticated.
2019-08-16T17:35:49.782214-04:00 INFO 75: HELO [{"i":"3e9476e221f03c0a/99cde4464e277749","a":"couchbase-net-sdk/2.7.11.1 (clr/4.0.30319.42000) (os/Microsoft Windows NT 6.3.9600.0)"}] XATTR, XERROR, Select bucket, Tracing [ xxx.xxx.xxx.xxx:59886 - xxx.xxx.xxx.xxx:11207 (not authenticated) ]
|
2019-08-16T17:35:49.801181-04:00 INFO 75 Closing connection [ xxx.xxx.xxx.xxx:59886 - xxx.xxx.xxx.xxx:11207 (not authenticated) ] due to read error: Connection reset by peer
|
2019-08-16T17:35:49.801185-04:00 WARNING 75: conn_read_packet_header - tryReadNetwork returned SocketError - closing connection [ xxx.xxx.xxx.xxx:59886 - xxx.xxx.xxx.xxx:11207 (not authenticated) ]
|
Additional instrumentation at the client showed connecting, issuing the select bucket, and then receiving EACCESS which would then make the client disconnect. The EACCESS does not seem to be logged at all.
It would help with debugging Cert Auth issues, and possibly other RBAC issues, if a select bucket is EACCESS rejected along with logging the reason for the access denial.
Request: can we log:
- Select bucket access denied, of course
- User authenticated as, or not authenticated
- Auth method
- Bucket user tried to auth to
- The client correlation ID from the HELO
I do note that http://src.couchbase.org/source/xref/6.0.0/kv_engine/daemon/mcbp_executors.cc#743 indicates there should have been some additional logging, but that was not found in memcached.log. The log from the failed attempt is above. Is there some reason it may return EACCESS without the logging?