2008/7/2 Stefan Kuhr winesku@googlemail.com:
Hello rob,
On 7/2/08, Rob Shearman robertshearman@gmail.com wrote:
<snip> That may be so, but it won't work for servers that only register the RPC_C_AUTHN_GSS_NEGOTIATE authentication scheme. So the patch should include a FIXME to warn users about this. Otherwise, the patch is fine.
Good to hear you think the patch could be accepted with a minor modification. However, with "servers that only register the RPC_C_AUTHN_GSS_NEGOTIATE authentication scheme", do you refer to an RPC server that makes a single call to RpcServerRegisterAuthInfo(.., RPC_C_AUTHN_GSS_NEGOTIATE,...)? If so, I assume you are wrong: I just made a test between two XP boxes in a non-domain environment and the server did a single call to RpcServerRegisterAuthInfo with RPC_C_AUTHN_GSS_NEGOTIATE. The client successully invoked an RPC on the server after having called RpcBindingSetAuthInfoEx with RPC_C_AUTHN_GSS_NEGOTIATE. However, if I change the server's code so it makes a single call to RpcServerRegisterAuthInfo with RPC_C_AUTHN_GSS_KERBEROS, the client fails with 1747 (RPC_S_UNKNOWN_AUTHN_SERVICE), but not in the call to RpcBindingSetAuthInfo but instead as the return value from the RPC that it calls immediately after RpcBindingSetAuthInfo.
So I think, it is not the responsibility of RpcBindingSetAuthInfoEx at this point to deal with a server only accepting Kerberos or Negotiate. Without knowing really too much how Windows actually implements this, my guts tell me that this is then the server's responsibility to reject a connection during the SSPI handshake which in WINE's code immediately follows the code that my patch would insert into RpcBindingSetAuthInfoEx
What do you think?
Interesting analysis and I'm sure you're right. However, the patch is still making up for a deficiency in another piece of code so it either needs a FIXME comment or a fixme to be printed to the debug log.