Re: to much syslogging by default

Jakub Jelen <[email protected]>
Newsgroups gmane.comp.security.cyrus.sasl
Message-ID <[email protected]>
Hi all,

I would like to follow this topic from the end of January:
http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2015-January/002785.html
Discussion about this continued in our bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1187097

I did some investigation under the hood of cyrus-sasl and finally I 
found a possible solution. When you grep through your plugins [ grep 
"\->log(" plugins/* ], some of them use construct that trows everything 
into syslog with ignoring LOG_LEVEL and user callbacks:
[...]->log(NULL, [...]

And some of them are using connection structure which enables them to 
log using own handler and whatever developer needs:
[..]->log([...]->conn, [..]

 From my point of view, there is no real order where is used which of 
these (if there is, I would be glad for some explanation). I see that 
digestmd5 is using conn _almost_ everywhere, but gssapi _almost_ nowhere.

I understand, that sometimes there is conn not available, but this is 
not the case. Pavel tested attached patch and confirmed that it solved 
his problem in SSSD. At this point I would like to open discussion here, 
if you are willing to apply this patch into upstream to give developers 
_some_ control over logging or if you can provide some comments on this.

Unfortunately previous thread died with resolution "I suspect you are 
right, as your analysis indicates.", because there was nobody with 
solution. Now there is solution so I would be glad for some constructive 
discussion to this issue.

Best Regards,
Jakub Jelen
cyrus-sasl-2.1.26-user-specified-logging.patch (text/x-patch, 1.3 KB)
diff --git a/plugins/gssapi.c b/plugins/gssapi.c
index 70a4157..7eb88d2 100644
--- a/plugins/gssapi.c
+++ b/plugins/gssapi.c
@@ -1267,7 +1267,7 @@ gssapi_server_mech_step(void *conn_context,
 
     if (text == NULL) return SASL_BADPROT;
 
-    params->utils->log(NULL, SASL_LOG_DEBUG,
+    params->utils->log(params->utils->conn, SASL_LOG_DEBUG,
 		       "GSSAPI server step %d\n", text->state);
 
     switch (text->state) {
@@ -1293,7 +1293,7 @@ gssapi_server_mech_step(void *conn_context,
 	break;
 
     default:
-	params->utils->log(NULL, SASL_LOG_ERR,
+	params->utils->log(params->utils->conn, SASL_LOG_ERR,
 			   "Invalid GSSAPI server step %d\n", text->state);
 	return SASL_FAIL;
     }
@@ -1499,7 +1499,7 @@ static int gssapi_client_mech_step(void *conn_context,
     *clientout = NULL;
     *clientoutlen = 0;
     
-    params->utils->log(NULL, SASL_LOG_DEBUG,
+    params->utils->log(params->utils->conn, SASL_LOG_DEBUG,
 		       "GSSAPI client step %d", text->state);
 
     switch (text->state) {
@@ -1992,7 +1992,7 @@ static int gssapi_client_mech_step(void *conn_context,
     }
 	
     default:
-	params->utils->log(NULL, SASL_LOG_ERR,
+	params->utils->log(params->utils->conn, SASL_LOG_ERR,
 			   "Invalid GSSAPI client step %d\n", text->state);
 	return SASL_FAIL;
     }
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.