Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero

[quanah@zimbra.com]

--On Tuesday, May 12, 2015 1:18 PM +0000 hyc@symas.com wrote:

> 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.

I think overall the design is problematic.  "ssf" is generally supposed to
indicate the overall security of the connection, regardless of the step.
Perhaps for 2.5 and later, we could modify the logging line to be something
more like:

May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND
dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256


So that the overall SSF of the connection is reflected, and we're
indicating that specifically the BIND op added nothing to SSF.

This would be useful for ldapi:/// connections as well, as there are zero
ssf indicators logged at all outside of the bind op:

May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from
PATH=/opt/zimbra/data/ldap/state/run/ldapi
(PATH=/opt/zimbra/data/ldap/state/run/ldapi)
May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND
dn="uid=zimbra,cn=admins,cn=zimbra" method=128
May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND
dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0
May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0
text=


Even though I have:

olcLocalSSF: 128

in my config DB

I.e., I think it would be better to show:

May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND
dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128

in this case.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration