Make use of the O_CLOEXEC flag when dealing with file descriptors #145
Conversation
kbabioch
force-pushed
the
feat/fdcloexec
branch
3 times, most recently
from
418dfef
to
e0b4cf6
Compare
This opens any file descriptors with the O_CLOEXEC flag, which will make sure that file descriptors won't be leaked into any child process. This was previously an issue due to a forgotten fclose() (Yubico#136).
This adds the `e` flag to fopen() calls, making sure the `O_CLOEXEC` flag is used. This makes sure that the file descriptor is being closed and not leaked into child processes. This was an issues previously due to a missing fclose() (Yubico#136).
This uses mkostemp() instead of mkstemp(), passing along the `O_CLOEXEC` flag, which makes sure that the file descriptor is closed and won't be leaked into any child process, which was previously an issue due to a missing fclose() (Yubico#136).
kbabioch
force-pushed
the
feat/fdcloexec
branch
from
e0b4cf6
to
0b595ee
Compare
|
An interesting thing here is that macos silently swallows the 'e' flag but doesn't seem to support it. O_CLOEXEC seems to be supported from 10.12 I'm unsure if it's better to switch to open()+fdopen() because of this to get the same protections for all files and all platforms.. thoughts? |
|
In my view this is definitely a feature that should be used as often as possible. Given that we already had an issue like this and we have a lot of Unfortunately I'm not a MacOS guy, so I don't have too much experience in this regard. Since there were no build errors from Travis, I assumed that everything is OK, and didn't give it a second thought.
I don't see another option, we probably need to work around these issue with open() and fdopen() as proposed by you. I'm happy to re-submit, but I'm cannot test on MacOS and have to rely on Travis, so if you want to tackle this for your own, feel free to do so ;). By the way: What are the minimum requirements on the MacOS side? Which is the oldest supported versions? Apparently other projects like Python and D-Bus had some issues with this flag, as it is not always available and had to put some conditionals around it. Is this something we need to worry about? |
|
I'll answer in reverse order here. For mac the support has to be latest + 1 (so 10.12 and 10.13). I agree that it makes sense to have the same behaviour on all platforms, using flags that are unsupported/ignored is a bad practice. |
…g fopen() A previous commit (d51124e) added the `e` flag to the `fopen()` calls. However this flag is not supported on all platforms (MacOS) and will be silently dropped (see Yubico#145). This patch works around those issues by manually opening the file descriptor using `open()` with the `O_CLOEXEC` flag, and invoking `fd_open()` on the resulting file descriptor to open an appropriate `FILE` stream. This makes sure that all files used by pam_yubico will be opened with the `O_CLOEXEC` flag on all supported platforms to mitigate issues with missing `fclose()` invocation (see Yubico#136).
|
Ok, I've added another commit (e5bd2ef) which should address the function. It is pretty straight forward, but let me know if there are any issues with it. |
…g fopen() A previous commit (d51124e) added the `e` flag to the `fopen()` calls. However this flag is not supported on all platforms (MacOS) and will be silently dropped (see Yubico#145). This patch works around those issues by manually opening the file descriptor using `open()` with the `O_CLOEXEC` flag, and invoking `fd_open()` on the resulting file descriptor to open an appropriate `FILE` stream. This makes sure that all files used by pam_yubico will be opened with the `O_CLOEXEC` flag on all supported platforms to mitigate issues with missing `fclose()` invocation (see Yubico#136).
kbabioch
force-pushed
the
feat/fdcloexec
branch
from
4d45bd3
to
e5bd2ef
Compare
|
Unfortunately the commit breaks the coveralls check. I'm not familiar with the test suite and it looks kind of hackery. @klali would you be willing to fix somehow increase the code coverage to make the check happy? Is this even necessary here? |
|
This looks good to me. I see the coverage check as more informative than something blocking us, the project needs more tests (especially for the challenge-response mode) but that isn't something that needs to block this. merging. |
This series makes use of the O_CLOEXEC flag whenever opening file descriptor, which makes sure that those file descriptors won't be leaked into child processes, even if a final
fclose()is forgotten (as was the case with #136).