-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make use of the O_CLOEXEC flag when dealing with file descriptors #145
Conversation
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).
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).
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).