problem with readonly pinfo?

[Christopher Faylor]

On Wed, Sep 17, 2003 at 12:40:46PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>> 
>> On Wed, Sep 17, 2003 at 12:03:00AM -0400, Pierre A. Humblet wrote:
>> >At 11:32 PM 9/16/2003 -0400, Christopher Faylor wrote:
>> >>On Tue, Sep 16, 2003 at 10:48:33PM -0400, Pierre A. Humblet wrote:
>> >>>>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)?
>> >>
>> >>I believe so, yes.
>> >>
>> >A solution for SIGCHLD could be to have an event just for that,
>> >settable by Everyone.
>> 
>> 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.

>One way or another we won't escape having something world writable and 
>having the reader/recipient decide if the message is legitimate. 
>With a pipe, is there a way for the reader to get the process id of the 
>writer, or some such?

I wish.  I was proposing that we could use a protocol where the sender
sends process info to the reader but that opens up the possibility of
a miscreant just sending random garbage to the pipe, leaving the reader
to have to somehow synchronize.  Of course, that is an issue with the
current implementation, too.  Sigh.

>> >I am looking at your changes in fhandler_process::fill_filebuf.
>> >By insisting on PID_MAP_RW we will be depriving ourselves (in the future)
>> >of the possibility of getting information that doesn't require writing.
>> 
>> The command line passing mechanism involves sending pseudo signals.  You
>> can't send a signal unless you've opened the pinfo region with
>> read/write.  The winpids code first tries to open the shared region with
>> RW and then drops back to read-only if it fails.
>
>Agreed. So you won't be able to get the command line if you don't have write
>access to the pinfo, which seems sensible from a security point of view.
>But the way the code is now (I think), fhandler_process::fill_filebuf () will
>(eventually) fail to return things such as the UID if the pinfo isn't writable.
>Actually I take back my suggestion. It's simpler to ask for PID_MAP_RW only when
>fileid == PROCESS_CMDLINE

"The winpids code first tries to open the shared region with RW and then
drops back to read-only if it fails."

So, a pinfo struct should be returned regardless of whether it can open the
shared region read/write.

>I also wrote:
>> >I am also mulling on the case of a process that setuids and execs.
>> >The resulting Windows process won't have access to the pinfo of its
>> >cygpid. That pinfo has been created long ago by its Windows grandfather.
>> >One would be to change the acl of the pinfo mapping before the exec.
>
>I fired up sysinternals and saw it will be a real problem. I will look
>into it in the coming days.

Thanks.  This is interesting stuff, isn't it?

cgf