I haven't used much shared memory. How would it work with shared memory ? I would have thought gss_init_sec_context/gss_accept-sec_context just gets a pointer and the underlying gss functions allocate the memory somewhere, not necessarily in the shared memory area ? How can you force the gss functions to use the shared memory ?
Thank you Markus "Michael B Allen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Sun, Oct 5, 2008 at 10:38 PM, Nicolas Williams > <[EMAIL PROTECTED]> wrote: >> On Sun, Oct 05, 2008 at 11:13:00PM +0100, Markus Moeller wrote: >>> Thank you for the replies. >>> >>> I get an GSS: error: "The token was a duplicate of an earlier token" and >>> debugging on the client shows that it received seq 0 but expected 1. So >>> I >>> need to dig a bit further what my server processes do. Is the following >>> OK : >>> >>> client <-> server main process establishes context -> export_context >>> client <-> child 1 import_context -> unwrap + wrap (seq 0) -> >>> export_context >>> client <-> child 2 import_context -> unwrap + wrap (seq 1)-> cleanup >> >> Do I understand correctly that you're importing a given exported >> security context token twice? >> >> If so, then "no, that's not supported." RFC2743 is quite clear on this. >> >> And it makes sense too: there may be no way for "child 1" and "child 2" >> to keep their sequence number windows in sync and perform as well as if >> they did not even try to keep them in sync. Also, the spec allows the >> second GSS_Import_sec_context() function call to fail, and it is >> possible to imagine implementations where such a failure would occur. >> >> Heck, even if an implementation supported multiple imports of one >> exported security context token you'd still have problems because >> whatever the per-message token sequence number window size is, if one >> process consumes/produces per-message tokens at a sufficiently different >> rate than the other then you'll still get sequencing errors. >> >> You could cheat and not request sequencing, but there's no guarantee >> that that will work either -- as long as you're importing the same >> exported security context token more than once then you're in trouble, >> and if it works it will be an accident of the mechanism's implementation >> and so your application will not be portable. > > Personally I think the whole export / import of security contexts is a > little awkward. Instead of moving the context we just put all IO > buffers in shared memory and have one process running the muxer loop > (although the reason for doing this has nothing to do with GSSAPI). > > Mike > > -- > Michael B Allen > PHP Active Directory SPNEGO SSO > http://www.ioplex.com/ > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
