quanah@openldap.org wrote:
Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177)
bind.c hard codes the output of the ssf= line in some of the stats logging to be zero, even if the connection actually has a higher ssf. For example:
Works as designed. The Bind op itself didn't provide any security, so it contributed 0 to the session's ssf. The preceding StartTLS request actually established a security layer, and it correctly logs the ssf from that.
Closing this ITS.
May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text=
Note how we have mech=SIMPLE, ssf=0
Since we ran startTLS, and it was established, we clearly do NOT have an ssf of zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success function:
/* log authorization identity */ Statslog( LDAP_DEBUG_STATS, "%s BIND dn=\"%s\" mech=%s ssf=0\n", op->o_log_prefix, op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 );There's a similar block in do_bind for anonymous binds as well:
if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) { /* log authorization identity demotion */ Statslog( LDAP_DEBUG_STATS, "%s BIND anonymous mech=implicit ssf=0\n", op->o_log_prefix, 0, 0, 0, 0 ); }It likely should be changed to use:
op->o_conn->c_ssf