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?


On Wed, Sep 17, 2003 at 03:48:41PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>>>>Yes, I know.  That would involve a new thread or removing one potential
>>>>process from the list of processes that are currently waited for in the
>>>>process thread.
>>>
>>>I was thinking about one event in catchem (sigproc) and the same kind
>>>of processing as what is done today.  Don't know how compatible that is
>>>with your new implementation.
>>
>>That would be perfect for the old method.  I'm just blocking on a pipe
>>now.  If MSFT actually implemented overlapped reads for pipes this
>>wouldn't be an issue.  I don't know why they limited things in this
>>fashion.
>>
>>>>>Also I wrote That doesn't solve the case of the group leader who isn't
>>>>>an ancestor.
>>>
>>>Actually it does.  The group leader could set the same event (or
>>>another event) as a child would, and set some kind of flag in its own
>>>pinfo.  The process seeing the event knows who its group leader is and
>>>can look up the flag in the leader pinfo.
>>
>>The one things I've been trying to avoid (now that you've got me
>>thinking about security) is the potential for a DOS.  The existence of
>>an event means that there's the possibility for a DOS.  It's probably
>>inavoidable though.
>
>Agreed, I don't see any way to avoid it.  However DOS attacks are near
>the bottom of my worries.  Here is another one: increase
>sys_mount_table_counter in the cygwin shared by 2,000,000,000 and watch
>all cygwin processes go read the registry 2000000000 times.  However
>the attacker gets nothing.

Yes, there are all sorts of ways to do this but I'm not going to design
in a guaranteed way to have a DOS if I can avoid it.  I've not been
checking in the pipe code in the hopes that some flash of inspiration
will come to me (that plus the fact that I'm getting writers cramp from
typing in the ChangeLog).

>>"The winpids code first tries to open the shared region with RW and
>>then drops back to read-only if it fails."
>
>I know you wrote that and I wondered why.  I may be really confused but
>I don't see how handler_process::fill_filebuf () uses winpids.  It
>deals with pinfo's directly.  kill_pgrp uses winpids.  You fixed both
>the same night (late)...

Oops.  Right.  Sorry.  I got the two confused.  And it doesn't actually
make any difference for kill_pgrp.  So, yes, I think your proposal to do
this in pinfo::init makes sense.

cgf


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