Problems on accessing Windows network resources
Pierre A. Humblet
Mon Jul 14 19:20:00 GMT 2003
Corinna Vinschen wrote:
> On Mon, Jul 14, 2003 at 01:32:56PM -0400, Pierre A. Humblet wrote:
> > After researching the issue, all cygwin routines I could find (not
> > only those ntsec related) initialize their handles to NULL, except
> > subauth() and create_token(). Those exceptions make sense because
> > those two must return INVALID_HANDLE_VALUE on error.
> > The patch itself avoids initializing any handle (avoiding ambiguity),
> > except the usual automatic initialization to 0 of the cygheap stuff.
> > Do you want my patch anyway (reverting what you have just applied),
> > or do we leave things as they are?
> INVALID_HANDLE_VALUE is also used to initialize local variables.
> I'd like to keep that value if you don't mind.
Turns out you are doing just the opposite of what I would have done,
but it's arbitrary anyway.
There is one slight problem, in seteuid32
/* Set process def dacl to allow access to impersonated token */
if (cygheap->user.current_token != new_token)
If the current_token is INVALID_.. (i.e. no impersonation), and there
is no change, new_token will be ptok (temporarily). Thus the test
will succeed when it should fail.
One way out is to:
- not initialize the local variable new_token
- set new_token to INVALID_.. if verifying ptok succeeds
- add a final else clause to the verify chain
new_token = NULL;
- call create_token (and? subauth) if new_token == NULL
That also allows to remove the test in
cygheap->user.current_token = new_token == ptok ? INVALID_HANDLE_VALUE
Now that I have done it anyway, I will send you a cleaned up version
of verify_token (unrelated to token initialization).
More information about the Cygwin-patches