|Summary:||opens files without CLOEXEC|
|Product:||poppler||Reporter:||Christian Persch (GNOME) <chpe>|
|Status:||RESOLVED MOVED||QA Contact:|
|i915 platform:||i915 features:|
Description Christian Persch (GNOME) 2018-08-16 20:22:06 UTC
Created attachment 141150 [details] [review] patch Poppler opens files without O_CLOEXEC. The attached patch fixes this in the libraries (but not the utils, since it doesn't matter there). Since there already is a fopen() wrapper in goo/gfile, I changed invocations of fopen() to use openFile instead, and made a macro wrapper around openFile that adds the "e" mode (meaning CLOEXEC). In the few places where open() is used instead of fopen(), I added O_CLOEXEC (with a fallback #define O_CLOEXEC 0 for those systems where O_CLOEXEC isn't defined). (There was a problem in glib/ where including gfile.h leads to a conflict with glib.h in that both define a "GDir" type; I resolved this by making gfile.h not define its GDir if GFILE_NO_GDIR is #define'd before inclusion. I would have renamed GDir -> GooDir, for example, but it appears that header is installed and thus would have been an API change.)
Comment 1 Albert Astals Cid 2018-08-17 16:43:13 UTC
Please explain the rationale for this patch
Comment 2 Christian Persch (GNOME) 2018-08-17 19:48:34 UTC
When a file isn't opened with O_CLOEXEC, and the process using the poppler library fork()+exec()es, the open file descriptor will leak from it to the spawned process, giving the new process access to a file it should not have access to.
Comment 3 GitLab Migration User 2018-08-20 22:02:41 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/170.