Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 153394 Details for
Bug 237731
Random SASL GSSAPI test failure on shadowfoot
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
cvs diff sasl_io.c and the fix description
sasl_io.html (text/html), 7.72 KB, created by
Noriko Hosoi
on 2007-04-25 01:29:03 UTC
(
hide
)
Description:
cvs diff sasl_io.c and the fix description
Filename:
MIME Type:
Creator:
Noriko Hosoi
Created:
2007-04-25 01:29:03 UTC
Size:
7.72 KB
patch
obsolete
><html> ><head> ><title>Re: Today's 3 accetance test failures</title> ><link rel="important stylesheet" href="chrome://messenger/skin/messageBody.css"> ></head> ><body> ><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> ><html> ><head> > <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> ></head> ><body bgcolor="#ffffff" text="#000000"> >The place where B1 (SLAPD_DISCONNECT_BAD_BER_TAG) is >set and returned is in the function connection_read_operation. It >calls connection_read_ldap_data and if 0 is returned, it considers the >connection is already closed and it cleans up the resource and return >CONN_DONE.<br> ><br> > 1684 int connection_read_operation(Connection *conn, Operation *op, >ber_tag_t *tag, int *remaining_data)<br> > 1685 {<br> > [...]<br> > 1734 /* We make a non-blocking read call */<br> > 1735 ret = connection_read_ldap_data(conn,&err);<br> > 1736 if (ret <= 0) {<br> > 1737 if (0 == ret) {<br> > 1738 /* Connection is closed */ <br> > 1739 PR_Lock( conn->c_mutex );<br> > <font color="#cc0000"><b>1740 >disconnect_server_nomutex( conn, conn->c_connid, -1, >SLAPD_DISCONNECT_BAD_BER_TAG, 0 );</b></font><br> > 1741 conn->c_gettingber = 0;<br> > 1742 PR_Unlock( conn->c_mutex );<br> > 1743 signal_listner();<br> > 1744 return CONN_DONE;<br> > 1745 }<br> ><br> >In connection_read_ldap_data, sasl_reciv_connection is called for the >SASL auth case. In the function, if nothing is in the decrypted buffer >(line 260 in the following snippet), it reads from the socket to fill >in the encrypted_buffer. And if "sasl_io_finished_packet(sp)" is true, >it thinks it read the enough size of encrypted data and decrypt it in >the decrypted_buffer. But, if "sasl_io_finished_packet(sp)" is false, >it does not do any further job, and since bytes_to_return is still 0, >it returns 0. That is, if the sasl request is not read by one call of >sasl_io_read_packet, it looks to me that the server misinterprets it >with B1 and closes the connection.<br> ><br> > 249 sasl_recv_connection(Connection *c, char *buffer, size_t >count,PRInt32 *err)<br> > 250 {<br> > 251 int ret = 0;<br> > 252 size_t bytes_in_buffer = 0;<br> > 253 sasl_io_private *sp = c->c_sasl_io_private;<br> > 254<br> > 255 *err = 0;<br> > 256 LDAPDebug( LDAP_DEBUG_CONNS,<br> > 257 "sasl_recv_connection for connection %d\n", >c->c_connid, 0, 0 );<br> > 258 /* Do we have decrypted data buffered from 'before' ? */<br> > 259 bytes_in_buffer = sp->decrypted_buffer_count - >sp->decrypted_buffer_offset;<br> > 260 if (0 == bytes_in_buffer) {<br> > 261 /* If there wasn't buffered decrypted data, we need to >get some. .. */<br> > 277 /* Are we there yet ? */<br> > 278 if (sasl_io_finished_packet(sp)) {<br> > 279 const char *output_buffer = NULL;<br> > [...]<br> > 301 }<br> > 302 /* Finally, return data from the buffer to the caller */<br> > 303 {<br> > 304 size_t bytes_to_return = sp->decrypted_buffer_count >- sp->decrypted_buffer_offset;<br> ><br> > This is sasl_io_finished_packet call:<br> > 183 static int<br> > 184 sasl_io_finished_packet(sasl_io_private *sp)<br> > 185 {<br> > 186 return (sp->encrypted_buffer_count && >(sp->encrypted_buffer_offset == sp->encrypted_buffer_count) );<br> > 187 }<br> > 188<br> ><br> >I haven't successfully reproduced it yet, so it may not be the exact >cause of the original problem, but I think we should support this >particular case... Here's my proposal. If it looks reasonable, I'm >opening a bug for this problem. <br> ><br> >Index: sasl_io.c<br> >===================================================================<br> >RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/sasl_io.c,v<br> >retrieving revision 1.10<br> >diff -t -w -U4 -r1.10 sasl_io.c<br> >--- sasl_io.c 10 Nov 2006 23:45:40 -0000 1.10<br> >+++ sasl_io.c 24 Apr 2007 01:34:08 -0000<br> >@@ -269,14 +269,16 @@<br> > }<br> > /* We now have the packet length<br> > * we now must read more data off the wire until we have the >complete packet<br> > */<br> >+ do {<br> > ret = sasl_io_read_packet(c,err);<br> > if (0 == ret || -1 == ret) {<br> > return ret;<br> > }<br> >- /* Are we there yet ? */<br> >- if (sasl_io_finished_packet(sp)) {<br> >+ } while (!sasl_io_finished_packet(sp));<br> >+ /* We are there. */<br> >+ {<br> > const char *output_buffer = NULL;<br> > unsigned int output_length = 0;<br> > LDAPDebug( LDAP_DEBUG_CONNS,<br> > "sasl_recv_connection finished reading packet for >connection %d\n", c->c_connid, 0, 0 );<br> ><br> ></body> ></html> ></body> ></html>
<html> <head> <title>Re: Today's 3 accetance test failures</title> <link rel="important stylesheet" href="chrome://messenger/skin/messageBody.css"> </head> <body> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> The place where B1 (SLAPD_DISCONNECT_BAD_BER_TAG) is set and returned is in the function connection_read_operation. It calls connection_read_ldap_data and if 0 is returned, it considers the connection is already closed and it cleans up the resource and return CONN_DONE.<br> <br> 1684 int connection_read_operation(Connection *conn, Operation *op, ber_tag_t *tag, int *remaining_data)<br> 1685 {<br> [...]<br> 1734 /* We make a non-blocking read call */<br> 1735 ret = connection_read_ldap_data(conn,&err);<br> 1736 if (ret <= 0) {<br> 1737 if (0 == ret) {<br> 1738 /* Connection is closed */ <br> 1739 PR_Lock( conn->c_mutex );<br> <font color="#cc0000"><b>1740 disconnect_server_nomutex( conn, conn->c_connid, -1, SLAPD_DISCONNECT_BAD_BER_TAG, 0 );</b></font><br> 1741 conn->c_gettingber = 0;<br> 1742 PR_Unlock( conn->c_mutex );<br> 1743 signal_listner();<br> 1744 return CONN_DONE;<br> 1745 }<br> <br> In connection_read_ldap_data, sasl_reciv_connection is called for the SASL auth case. In the function, if nothing is in the decrypted buffer (line 260 in the following snippet), it reads from the socket to fill in the encrypted_buffer. And if "sasl_io_finished_packet(sp)" is true, it thinks it read the enough size of encrypted data and decrypt it in the decrypted_buffer. But, if "sasl_io_finished_packet(sp)" is false, it does not do any further job, and since bytes_to_return is still 0, it returns 0. That is, if the sasl request is not read by one call of sasl_io_read_packet, it looks to me that the server misinterprets it with B1 and closes the connection.<br> <br> 249 sasl_recv_connection(Connection *c, char *buffer, size_t count,PRInt32 *err)<br> 250 {<br> 251 int ret = 0;<br> 252 size_t bytes_in_buffer = 0;<br> 253 sasl_io_private *sp = c->c_sasl_io_private;<br> 254<br> 255 *err = 0;<br> 256 LDAPDebug( LDAP_DEBUG_CONNS,<br> 257 "sasl_recv_connection for connection %d\n", c->c_connid, 0, 0 );<br> 258 /* Do we have decrypted data buffered from 'before' ? */<br> 259 bytes_in_buffer = sp->decrypted_buffer_count - sp->decrypted_buffer_offset;<br> 260 if (0 == bytes_in_buffer) {<br> 261 /* If there wasn't buffered decrypted data, we need to get some. .. */<br> 277 /* Are we there yet ? */<br> 278 if (sasl_io_finished_packet(sp)) {<br> 279 const char *output_buffer = NULL;<br> [...]<br> 301 }<br> 302 /* Finally, return data from the buffer to the caller */<br> 303 {<br> 304 size_t bytes_to_return = sp->decrypted_buffer_count - sp->decrypted_buffer_offset;<br> <br> This is sasl_io_finished_packet call:<br> 183 static int<br> 184 sasl_io_finished_packet(sasl_io_private *sp)<br> 185 {<br> 186 return (sp->encrypted_buffer_count && (sp->encrypted_buffer_offset == sp->encrypted_buffer_count) );<br> 187 }<br> 188<br> <br> I haven't successfully reproduced it yet, so it may not be the exact cause of the original problem, but I think we should support this particular case... Here's my proposal. If it looks reasonable, I'm opening a bug for this problem. <br> <br> Index: sasl_io.c<br> ===================================================================<br> RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/sasl_io.c,v<br> retrieving revision 1.10<br> diff -t -w -U4 -r1.10 sasl_io.c<br> --- sasl_io.c 10 Nov 2006 23:45:40 -0000 1.10<br> +++ sasl_io.c 24 Apr 2007 01:34:08 -0000<br> @@ -269,14 +269,16 @@<br> }<br> /* We now have the packet length<br> * we now must read more data off the wire until we have the complete packet<br> */<br> + do {<br> ret = sasl_io_read_packet(c,err);<br> if (0 == ret || -1 == ret) {<br> return ret;<br> }<br> - /* Are we there yet ? */<br> - if (sasl_io_finished_packet(sp)) {<br> + } while (!sasl_io_finished_packet(sp));<br> + /* We are there. */<br> + {<br> const char *output_buffer = NULL;<br> unsigned int output_length = 0;<br> LDAPDebug( LDAP_DEBUG_CONNS,<br> "sasl_recv_connection finished reading packet for connection %d\n", c->c_connid, 0, 0 );<br> <br> </body> </html> </body> </html>
View Attachment As Raw
Actions:
View
Attachments on
bug 237731
: 153394 |
153451
|
153651
|
154692