This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.


On Mon, Nov 22, 2004 at 01:20:45PM -0500, Igor Pechtchanski wrote:
>On Mon, 22 Nov 2004, Christopher Faylor wrote:
>
>> On Mon, Nov 22, 2004 at 12:46:46PM -0500, Igor Pechtchanski wrote:
>> >Can the code simply propagate the actual exit code into the exitcode
>> >field (since Windows programs don't know about signals)?
>>
>> And who would use it?  How would a UNIX program know that the "negative"
>> exit code represented a windows error code?  A UNIX program would
>> interpret the low order bytes as indicating a signal number and would
>> think that there was a core dump if the appropriate bit was set.  The
>> exitcode field is just for use by the cygwin DLL.  There is no way for a
>> UNIX program to get more than eight bits (seven bits for signals) of
>> exit code from a process.
>
>Isn't that exactly what I said in the part that was snipped?

Sort of, but then it's also close what I said I was doing in the
original message, too, except I said "error code" instead of "exit
code", maybe that's where the confusion lies:

*I've also added an 'exitcode' field to _pinfo so that a Cygwin process
*will set the error (sic) code in a UNIX fashion based on whether it is
*exiting *due to a signal or with a normal exit().

Since a windows program can't exit "due to a signal" the only
alternative would be to consider it an exit code.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]