Skip to content
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

unsafe usage of evt_tag_errno #1990

Closed
furiel opened this issue Apr 15, 2018 · 2 comments
Closed

unsafe usage of evt_tag_errno #1990

furiel opened this issue Apr 15, 2018 · 2 comments
Assignees
Labels

Comments

@furiel
Copy link
Collaborator

furiel commented Apr 15, 2018

There are evt_tag_errno calls all around the code that use the errno variable directly. In some cases it is not safe, because other evt_tags in msg_(error/warning/etc) can call functions that can overwrite errno. For example in the snippet below, either malloc or strdrup in evt_tag_str can overwrite errno.

As compiler is free to evaluate parameters in any order, it is not enough to move evt_tag_errno to the first parameter.

      cap_text = cap_to_text(caps, NULL);
      msg_error("Error managing capability set, cap_set_proc returned an error",
                evt_tag_str("caps", cap_text),
                evt_tag_errno("error", errno));

The resolution would be to store errno on the stack, and pass the local variable to errno.

As a bonus: evt_tag_errno might disallow users to pass errno directly: for example compare if &errno is passed to it, and assert in that case. G_LIKELY/UNLIKELY can be used inside the if statement for optimization.

As an estimate, 64/76 of evt_tag_errno uses errno directly.

$ ag evt_tag_errno | grep -F "errno)" | wc -l
64
$ ag evt_tag_errno | wc -l
76
@gaborznagy gaborznagy added the bug label Apr 16, 2018
@bazsi
Copy link
Collaborator

bazsi commented Apr 18, 2018 via email

@furiel
Copy link
Collaborator Author

furiel commented Apr 19, 2018

Abort on allocation problems is unfortunately not enough: due to evt_tag_printf, users can involve any kind of calls that dynamically captures errno, and not related to allocation errors. For examle in evt_tag_str(..., g_sockaddr_format(...)), we will implicitely call inet_ntop which can capture errno.

But I agree it would be best if we could hide this detail inside evtlog. I am interested in this, let me try to do some macromagic: see if I can lexically capture errno, store it in a gensym, and make evt_tag_errno expand into a call that receives the captured errno in the gensym. I might even be able to maintain api compatibility: evt_tag_errno might check if user passed an errno, and in that case, go with it instead of the gensym.

@furiel furiel self-assigned this Apr 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants