)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"5bcb16a8ad08cd21ef48ba355859632e2706d3a3","unresolved":false,"context_lines":[{"line_number":13,"context_line":"benchmark.py reports an overhead of ~ 400ms without this patch and 2ms"},{"line_number":14,"context_line":"with the patch applied. This patch adds a configuration option and"},{"line_number":15,"context_line":"leaves it disabled for the stable/* backports to not change default"},{"line_number":16,"context_line":"behavior."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Also includes Ben Nemec\u0027s release note entry, adjusted for the stable"},{"line_number":19,"context_line":"backport. This is Ib29e96307caa39c21936f216d9aed7907e7a7331 for master."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"1f769fc5_6805477a","line":16,"updated":"2018-12-23 23:56:28.000000000","message":"Isn\u0027t this a security problem?\n\nSay I have a daemon that runs with a ulimit RLIMIT_NOFILE (2048, 4096) and I have 2048 files open.  Then I call a rootwrap process with rlimit_nofile\u003d1024.  won\u0027t fd\u0027s 1025..2048 get left open in the child?\n\nAs rlimit_nofile isn\u0027t tied in any way to the process ulimt it\u0027d be trivial for an operator to bump the latter and not the former.","commit_id":"d0b06624bb82253076af2b76753b22ed3a2e042d"},{"author":{"_account_id":6593,"name":"Dirk Mueller","email":"dirk@dmllr.de","username":"dmllr"},"change_message_id":"973cc265e3411184ae2fe1f98f8e623bad265cce","unresolved":false,"context_lines":[{"line_number":13,"context_line":"benchmark.py reports an overhead of ~ 400ms without this patch and 2ms"},{"line_number":14,"context_line":"with the patch applied. This patch adds a configuration option and"},{"line_number":15,"context_line":"leaves it disabled for the stable/* backports to not change default"},{"line_number":16,"context_line":"behavior."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Also includes Ben Nemec\u0027s release note entry, adjusted for the stable"},{"line_number":19,"context_line":"backport. This is Ib29e96307caa39c21936f216d9aed7907e7a7331 for master."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"1f769fc5_95a8bcdb","line":16,"in_reply_to":"1f769fc5_6805477a","updated":"2019-01-02 14:50:03.000000000","message":"Yes, in this scenario the fds 1025..2048 will get left open in the child. From my perspective passing a fd (that was opened by an unprivileged process like e.g. nova-compute) to a root running process is annoying but not a security problem (it would be worse in the opposite case, where a fd that is maybe only accessible by root would be leaked to non-root). a root process might be able to look at any fd on the system anyway, no matter where it is or where it is going to.\n\nwe can improve the documentation to say that one should not have too high of a fd limit set by default to not do this change, or backport a linux specific way of closing the fds more efficiently. I can do that as a new commit to master. \n\nPlease note that the backport is effectively a noop right now so it doesn\u0027t make the situation any different by *default*. \n\nRegarding the daemon mode - in daemon mode the \"subprocess.Popen(..., close_fds\u003dTrue)\" is called by every command that is executed by the daemon-mode process, so the performance overhead also exists there. daemon mode optimizes away the startup cost of the python interpreter and the regexp/parsing overhead of the filters, but everything else remains the same.","commit_id":"d0b06624bb82253076af2b76753b22ed3a2e042d"}]}