This is the mail archive of the cygwin-developers@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: problem with readonly pinfo?


At 10:20 PM 9/16/2003 -0400, Christopher Faylor wrote:
>On Tue, Sep 16, 2003 at 09:59:17PM -0400, Pierre A. Humblet wrote:
>>At 09:46 PM 9/16/2003 -0400, Christopher Faylor wrote:
>>>The problem is that UNIX sends signals (like CTRL-C) to processes in a
>>>process group, regardless of process ownership.  In cygwin, it's up to
>>>the parent process to do this.
>>
>>I am not sure I understand 100% what "up to the parent process" means.
>>Do you mean the signals are propagated through generations (grandfather
>>to father to child) and not directly from grandfather to grandchild as
>>in UNIX?
>
>Wow.  This is hard.
>
>If you type CTRL-C on windows, any process in the tty process group
>gets sent a CTRL-C.
>
>How do you think this is handled in cygwin?  There is no help from the
>operating system since the operating system doesn't know what a unix
>process group is.
>
>So, some process in cygwin has to send CTRL-Cs to everything in the
>process group.  This is left to the process group leader.
>
>In practice, the process gruop leader is usually the top level process
>of a process tree although it could theoretically be a descendant
>process.  Hmm.  This just occurred to me.
>
>When the process group leader has not created all of the processes
>in its group, I don't think the new scheme will work right, will it?

I assume that by "created" you mean "created directly".
It won't be any worse than today. If there was no setuid, they all have the
same sid, no problem. If they don't have the same sid, the ancestor is
in Admins, in practice.
There is a theoretical possibility that the ancestor isn't. The solution
would be to transmit the sid of the leader down the cygheap.
There is trouble ahead when the process group leader is a descendant 
process itself, in a branch that has setuid'ed.

>It's a similar problem to:
>
>>>I think you're saying that this will work ok, right?  And we should be
>>>able to use the same security for the pipe as well, I assume?
>>
>>Yes.  But I see a problem going in the other direction, from a child
>>who has setuid'ed and exec'ed, to parent.  At least with the current
>>code, hopefully not with your pipes.
>
>Yes, I know about those problems.  That's why I haven't checked in the
>pipe stuff yet.

Is SIGCHLD the only case where that occurs (in addition to the process
group leader who isn't an ancestor)? 

Pierre


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