Re: problem with readonly pinfo?

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

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.

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. 
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 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

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.

Pierre