Patch for [Bug 14222] RpcBindingSetAuthInfo(Ex) fails with RPC_C_AUTHN_GSS_NEGOTIATE
Hello everyone, please find attached a patch for Bug 14222. IIRC I sent a similar patch a year ago or so and never received feedback why it was rejected. Austin encouraged me to send it again, so please if it is unacceptable, let me know why. The patch will make RPC clients work that are written for Windows 2000 (and later), where the negotiate provider performs an automatic fallback to NTLM, if Kerberos is not possible, both in workgroup and domain scenarios. Currently, Wine doesn't have a negotiate and a Kerberos provider. This patch allows clients requesting Negotiate to get the NTLM provider and will still work, even if one day negotiate and Kerberos providers will be added to Wine. Cheers, -- Stefan 0001-Fallback-from-negotiate-to-ntlm-if-no-negotiate-prov.patch Description: Binary data
Re: How do I write an exception filter?
Hello everyone, On 7/10/08, Juan Lang [EMAIL PROTECTED] wrote: snip Now that we've established you can't do this yourself, a hint on how you can help us: file a bug describing the problem, and produce as small a test case as you can that shows the problem in Wine. Ideally you can write a regression test that succeeds on Windows and fails on Wine. That should give the devs here a pretty strong hint about what needs to be done. Done, it's Bug #14465. It contains source code and binaries for a windows RPC client and server that allows to use a variety of RPC calls with different comm and fault status decoration of the RPC calls and client side diagnosis of what exceptions are legitimate and what are erroneous. I have also a attached a patch with the result of my work regarding this problem. The source code for this patch has been written before I started debugging the XP implementation of NdrClientCall2 and has been created by analysing the MIDL generated source code for my test project. I hope this all can help to fix this problem. If anyone needs help with my code or my test project, don't hesitate to contact me. Cheers, -- Stefan
Re: Fallback from RPC_C_AUTHN_GSS_NEGOTIATE to RPC_C_AUTHN_WINNT if no SPNEGO package available
Hi Rob, On Thu, Jul 3, 2008 at 10:20 AM, Stefan Kuhr [EMAIL PROTECTED] wrote: snip Ok, I'll do that and resend the modified patch. It probably also needs a fixme for an entire different reason: Once a Negotiate provider is available in WINE, my patch won't do any harm, but it is going to be dead code that can be removed then. I already sent a revised patch to the patch mailing list a week ago. Do you think that one is now acceptable? Cheers, -- Stefan Kuhr
How do I write an exception filter?
Hello everyone,
I would like to know what the proper way is to write an exception
filter function for WINE code. Most of the WINE exception filtering
seems to be done with the __EXCEPT_PAGE_FAULT macro, for whatever
reason. In all other places I see the macro __EXCEPT with a filter
function of this prototype
LONG WINAPI filter(EXCEPTION_POINTERS *);
However, I have the need to implement a filter function that takes
additional formal parameters such as the values of local parameters of
the function where the SEH frame resides. Alternatively, I would like
to do something like the following (in MSVC parlance), where the
exception filter is a simple boolean expression:
__try
{
PDWORD pdwCommStatus = ;
PDWORD pdwFaultStatus = ;
doSomething();
}
__except( (pdwCommStatus||pdwFaultStatus) ? EXCEPTION_EXECUTE_HANDLER
: EXCEPTION_CONTINUE_SEARCH )
{
// handle the exception
}
In include/wine/exception.h, a comment from AJ says that
__EXCEPT(filter_func,param) is the proper way to do it but param
is not explained at all and filter_func must be defined with the
WINE_EXCEPTION_FILTER macro, as the comment says. However, a search
for WINE_EXCEPTION_FILTER yields no results.
So, how do I do these things in WINE properly? Did I overlook something obvious?
--
Stefan
Re: How do I write an exception filter?
Hello Ove,
On Thu, Jul 10, 2008 at 9:55 PM, Ove Kaaven [EMAIL PROTECTED] wrote:
snip
In general, within Wine code, it's impossible. In standard C, a function
cannot reference a local variable of another function. It might be possible
with some trickery (e.g. declaring explicit register/volatile variables), or
with special compiler support (MSVC obviously has special support for it,
and perhaps gcc nested functions or something could be used).
For Wine, you'd have to come up with something else. Whatever the filter
function needs should be available in some other form than a stack variable,
like maybe some global or thread-local (TLS) variable, or perhaps from some
function call.
Maybe there is something I simply don't understand. What I mean is
something like this:
__try
{
PDWORD pdwCommStatus = ;
PDWORD pdwFaultStatus = ;
doSomething();
}
__except(MySpecialFilter(GetExceptionCode(),pdwCommStatus, pdwFaultStatus) )
{
// handle the exception
}
This is something quite common in Win32, as far as I can tell. As an
alternative, I would like to use the simple ternary operation in the
code snippet in my OP. Maybe I am too ignorant, because I have only
coded for Windows the last 15 years and I have some difficulties now
trying to prepare a patch for WINE, so bear with me, but I cannot see
why that would be trickery.
Also perhaps consider whether you need a filter function this complex at
all...
I need that. I would like to implement comm status and fault status
awareness in WINE's rpcrt4, because my applications crash in WINE
because of the lack of proper comm status and fault status awareness
in WINE's RPC implementation. From debugging NdClientCall2 in XP I
deduce I need this.
Cheers,
--
Stefan Kuhr
Re: How do I write an exception filter?
Hi everyone,
On Thu, Jul 10, 2008 at 10:24 PM, Stefan Kuhr [EMAIL PROTECTED] wrote:
Hello Ove,
On Thu, Jul 10, 2008 at 9:55 PM, Ove Kaaven [EMAIL PROTECTED] wrote:
snip
In general, within Wine code, it's impossible. In standard C, a function
cannot reference a local variable of another function. It might be possible
with some trickery (e.g. declaring explicit register/volatile variables), or
with special compiler support (MSVC obviously has special support for it,
and perhaps gcc nested functions or something could be used).
For Wine, you'd have to come up with something else. Whatever the filter
function needs should be available in some other form than a stack variable,
like maybe some global or thread-local (TLS) variable, or perhaps from some
function call.
Maybe there is something I simply don't understand. What I mean is
something like this:
__try
{
PDWORD pdwCommStatus = ;
PDWORD pdwFaultStatus = ;
doSomething();
}
__except(MySpecialFilter(GetExceptionCode(),pdwCommStatus, pdwFaultStatus) )
{
// handle the exception
}
Oh stupid me.
PDWORD pdwCommStatus = ;
PDWORD pdwFaultStatus = ;
should be placed outside the try block.
--
Stefan Kuhr
Re: How do I write an exception filter?
Hi Juan, On Thu, Jul 10, 2008 at 10:28 PM, Juan Lang [EMAIL PROTECTED] wrote: I need that. I would like to implement comm status and fault status awareness in WINE's rpcrt4, because my applications crash in WINE because of the lack of proper comm status and fault status awareness in WINE's RPC implementation. From debugging NdClientCall2 in XP I deduce I need this. I hate to be the one to break it to you, but debugging ndrclientCall2 in XP precludes you from contributing to wine's implementation. --Juan Oh, I did not know that. What should I do now? Does that mean I can never ever contribute something to improve that function? -- Stefan
Re: How do I write an exception filter?
H everyone, On Thu, Jul 10, 2008 at 10:34 PM, Juan Lang [EMAIL PROTECTED] wrote: Oh, I did not know that. What should I do now? Does that mean I can never ever contribute something to improve that function? I'm afraid so. --Juan Stupid me. How could I have prevented that? Is there some sort of 'Code of Ethics' of the WINE project that I should have read before and that tells me not to debug a binary from MS in order to improve a WINE implementation? -- Stefan
Re: How do I write an exception filter?
Hello everyone,
On Thu, Jul 10, 2008 at 10:30 PM, Stefan Kuhr [EMAIL PROTECTED] wrote:
__try
{
PDWORD pdwCommStatus = ;
PDWORD pdwFaultStatus = ;
doSomething();
}
__except(MySpecialFilter(GetExceptionCode(),pdwCommStatus, pdwFaultStatus) )
{
// handle the exception
}
Oh stupid me.
PDWORD pdwCommStatus = ;
PDWORD pdwFaultStatus = ;
should be placed outside the try block.
Now that we all know that I cannot contribute anymore to improving
NdrClientCall2 and that I also failed to properly write a code snippet
that obeys variable scope rules, could someone give an answer to my
original problem?
OMG, this afternoon is a real disaster :-(
Thanks,
--
Stefan Kuhr
Re: Fallback from RPC_C_AUTHN_GSS_NEGOTIATE to RPC_C_AUTHN_WINNT if no SPNEGO package available
Hi Rob, On Wed, Jul 2, 2008 at 11:51 PM, Rob Shearman [EMAIL PROTECTED] wrote: snip 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. Ok, I'll do that and resend the modified patch. It probably also needs a fixme for an entire different reason: Once a Negotiate provider is available in WINE, my patch won't do any harm, but it is going to be dead code that can be removed then. Cheers, -- Stefan
Re: Fallback from RPC_C_AUTHN_GSS_NEGOTIATE to RPC_C_AUTHN_WINNT if no SPNEGO package available
Hello rob, On 7/2/08, Rob Shearman [EMAIL PROTECTED] 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? Cheers, -- Stefan
