DO NOT REPLY [Bug 36995] - duplicate session ids
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36995 --- Additional Comments From [EMAIL PROTECTED] 2005-10-12 14:09 --- (In reply to comment #4) We have Suse 8.2 with kernel 2.4.20-64GB-SMP on our servers. Java version is 1.4.2_03 and Tomcat 4.1.29. As the chances for the described scenario are slim, I suggest to reduce the value of ManagerBase.SESSION_ID_BYTES from 16 to 2 or 3 for testing. This should increase the chances of duplicates returned by ManagerBase.generateSessionId() without affecting the behaviour of Tomcat. Additionally, I put a Thread.yield() below the end of the sychronized block in ManagerBase.createSession(), to provoke the racing time condition, further increasing the chances for the scenario. Then I started Tomcat with the JSP page session.jsp: %@ page language=java %%= request.getSession().getId() % The test application performs repeated request from different threads, recoding the returned session ids and checking for duplicates. Even with the reduced random range it might take several runs to stumble into a duplicate. I'm sure there are better ways to test it, it is just a simple test. I'm not saying this is an urgent problem, or that it happens all the time, I merely think that it can happen, because random numbers, however large the range might be, are not unique by themselves, are they? And if it can happen, it will happen, eventually. Or am I missing something here? The whole idea of even checking for duplicates is a nonsense (beyond giving people some sense of safety). If the id generation has conflicts, then it means the system is completely insecure, so fixing a bug which will never actually occur doesn't have any benefits. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36995] - duplicate session ids
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36995 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 09:09 --- (In reply to comment #1) I hava look inside also inside 5.5.x code (ManagerBase.generateSessionId()) and think the duplication risk is there. But the risk is small, as random generator works really good. I have test with Linux Suse 9.3 and have no chance to reproduce your test result. Can you please send your testscripts and os information? This does not make any sense. The risk does not exist, and the uniqueness check is just there to make insecure people more secure. I am actually tired of it, and would want it removed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36995] - duplicate session ids
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36995 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 14:01 --- Created an attachment (id=16657) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16657action=view) A simple test case to check for duplicate session ids. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36995] - duplicate session ids
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36995 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 14:02 --- We have Suse 8.2 with kernel 2.4.20-64GB-SMP on our servers. Java version is 1.4.2_03 and Tomcat 4.1.29. As the chances for the described scenario are slim, I suggest to reduce the value of ManagerBase.SESSION_ID_BYTES from 16 to 2 or 3 for testing. This should increase the chances of duplicates returned by ManagerBase.generateSessionId() without affecting the behaviour of Tomcat. Additionally, I put a Thread.yield() below the end of the sychronized block in ManagerBase.createSession(), to provoke the racing time condition, further increasing the chances for the scenario. Then I started Tomcat with the JSP page session.jsp: %@ page language=java %%= request.getSession().getId() % The test application performs repeated request from different threads, recoding the returned session ids and checking for duplicates. Even with the reduced random range it might take several runs to stumble into a duplicate. I'm sure there are better ways to test it, it is just a simple test. I'm not saying this is an urgent problem, or that it happens all the time, I merely think that it can happen, because random numbers, however large the range might be, are not unique by themselves, are they? And if it can happen, it will happen, eventually. Or am I missing something here? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36995] - duplicate session ids
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36995 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-10-10 19:58 --- I hava look inside also inside 5.5.x code (ManagerBase.generateSessionId()) and think the duplication risk is there. But the risk is small, as random generator works really good. I have test with Linux Suse 9.3 and have no chance to reproduce your test result. Can you please send your testscripts and os information? Thanks Peter -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
