problem with readonly pinfo?
Wed Sep 17 18:10:00 GMT 2003
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
>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?
More information about the Cygwin-developers