Fwd: kprocess - close all open files in the child
bastian at kde.org
Thu Dec 19 12:16:39 GMT 2002
On Thursday 19 December 2002 12:45, Lubos Lunak wrote:
> On Thursday 19 of December 2002 12:30, Waldo Bastian wrote:
> > Oh, sorry, didn't notice this message until now. I reverted it because it
> > breaks backwards compatibility as well as the error reporting by KProcess
> > (it uses a pipe between the child and the parent to communicate start-up
> > errors)
> Oops, sorry. But that's just another if() added to the loop.
> > I think the security impact is minimal because the child process would
> > normally be able to open the fd itself as well. I agree that it is not
> > nice
> It's not only files, looking at /proc/<pid>/fd for xterm started from
> minicli shows 9 more fds, most of them being pipes (no idea where they come
> from, seeing in mc the symlink pointing to pipe: doesn't help
> much). Just having files open isn't a problem, but does the same apply also
> for fds for various pipes/socketpairs?
> > to have file descriptors lying around in child processes but I don't want
> > to break backwards compatibility this short before 3.1 without offering
> > at least an alternative way to pass file-descriptors to the child
> > process.
> Yes, I think we can have another release with the fds left open, when we
> had some many of them with it already (it actually wasn't me who backported
> this). But I still think we should close all fds there, maybe with having
> KProcess::dontCloseFds( fd_set ) for the rare case when people want to pass
> more fds to the new process.
I'm currently adding Pty support to KProcess for KDE 3.2, I will add a
KProcess::passFd(int fd) and then close everything else.
For 3.1 I will hunt down these pipes and set their close-on-exec flag.
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
More information about the kde-core-devel