On Mon, Jul 14, 2003 at 11:25:18PM -0400, Pierre A. Humblet wrote:
Corinna,
As announced, this patch is only about style conformance and
efficiency. You have already applied the bug fix part.
Pierre
2003-07-15 Pierre Humblet [EMAIL PROTECTED]
* security.cc (verify_token):
Hi Pierre,
On Fri, Jul 11, 2003 at 08:02:53PM -0400, Pierre A. Humblet wrote:
2003-07-12 Pierre Humblet [EMAIL PROTECTED]
* cygheap.h (enum impersonation): Delete.
(cygheap_user::impersonation_state): Delete.
(cygheap_user::current_token): New.
Corinna Vinschen wrote:
Hi Pierre,
I've applied this patch. I've just changed the code to use
INVALID_HANDLE_VALUE instead of NULL throughout.
Thanks,
Corinna
Hi Corinna,
I was going to send you the modified patch tonight, with some extra
cleanup added.
After researching the
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
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
At 10:31 AM 7/12/2003 +0200, Corinna Vinschen wrote:
thanks for the patch but it has a problem. You're comparing tokens against
NULL while the correct NULL value for tokens is INVALID_HANDLE_VALUE.
Corinna,
That's by design, using of Chris' astute observations. As he once
pointed out,
On Sat, Jul 12, 2003 at 09:37:37AM -0400, Pierre A. Humblet wrote:
At 10:31 AM 7/12/2003 +0200, Corinna Vinschen wrote:
thanks for the patch but it has a problem. You're comparing tokens against
NULL while the correct NULL value for tokens is INVALID_HANDLE_VALUE.
Corinna,
That's by
Hi Pierre,
On Wed, Jun 11, 2003 at 11:03:36PM -0400, Pierre A. Humblet wrote:
Corinna,
Here is the patch to preserve the external token.
Looks good. I like especially the deimpersonate/reimpersonate methods.
You will see that cygwin_set_impersonation_token() should
now return a
Corinna Vinschen wrote:
You will see that cygwin_set_impersonation_token() should
now return a success/failure indication, instead of void.
That's not done yet, waiting for your opinion.
How do you intend to use that return value?
If changing the type to return a value is likely to
On Thu, Jun 12, 2003 at 12:01:31PM -0400, Pierre A. Humblet wrote:
If changing the type to return a value is likely to break
existing applications, I would no do it.
I don't think so. Well... it might in case the compiler's optimizer
relied somehow on the fact that the function didn't return a
Corinna Vinschen wrote:
On Thu, Jun 12, 2003 at 12:01:31PM -0400, Pierre A. Humblet wrote:
If changing the type to return a value is likely to break
existing applications, I would no do it.
I don't think so. Well... it might in case the compiler's optimizer
relied somehow on the fact
On Thu, Jun 12, 2003 at 12:56:31PM -0400, Pierre A. Humblet wrote:
Corinna Vinschen wrote:
I don't understand what you mean. The call would nevertheless replace
the old token so what means noop here?
Nope, the old token isn't replaced (in the patch).
Ouch, I misread the patch. I'm not
Corinna,
consider the issue with cygwin_set_impersonation_token()
solved. I found a nice way out, leaving it void. I will
send a patch after the current one is taken care of.
Pierre
Corinna,
Here is the patch to preserve the external token.
After mulling over the issue, I settled on a solution
close to what I had initially in mind, i.e. separate
external and internal tokens. It always behaves as
expected, we don't have to assume anything about what
the application expects
14 matches
Mail list logo