Summary:
Pull Request resolved: https://github.com/facebook/osquery/pull/5390
to eliminate the effect of dropping privileges in other threads causing poll-ing EINTR errors in thrift.
According to ref to [bugzilla.redhat](https://bugzilla.redhat.com/show_bug.cgi?id=473907) in case of changing privileges `glibc` sends SIGRT_1 to other threads which lead to poll be interrupted. On posix we can not have different credentials for thread of one process. Therefore the solution is either to do not use dropping privileges for the whole osquery process or patch all usages of poll in thrift code. I like first option more because playing with permissions of the whole `osqueryd` can cause unpredicted interferences between threads. For instance the same table can provide different results because some other thread dropping and regaining privileges at the same time.
So, the solution for now I'd like to suggest is remove dropping privileges from safe places like reading files with known hostnames or shell history files. And because we can not interact with apt/rpm/yum databases as root and should drop to none user for it I'd suggest to increase the number of attempts to poll in case of EINTR. It can significantly eliminate the problem for now.
To address the problem in issue: [#5326](https://github.com/facebook/osquery/issues/5326)
Thanks fmanco for the help to investigate this problem.
Reviewed By: fmanco
Differential Revision: D13781886
fbshipit-source-id: 4b1f2b7d20c925cc19ba79cc0a2906b65e815c0b
Summary:
Pull Request resolved: https://github.com/facebook/osquery/pull/5375
LICENSE is now defined in a single file on the root of the project, update the
header to contain that information.
**Project LICENSE did not change.**
Reviewed By: akindyakov
Differential Revision: D13750575
fbshipit-source-id: 1e608a81b260b8395f9d008fc67f463160c1fc2b
Summary:
While running `misspell` on a different codebase. I happened to notice that some misspellings in the osquery code base. So, I fixed them
Pull Request resolved: https://github.com/facebook/osquery/pull/5256
Reviewed By: guliashvili
Differential Revision: D13670897
Pulled By: fmanco
fbshipit-source-id: 5d33d858284955c376e8c3980acdf366d4edf3d3
Summary: Windows named pipe requires a bit different name format in compare to posix platforms.
Reviewed By: guliashvili
Differential Revision: D13376805
fbshipit-source-id: 443c8f963863adbacd1edb76945919f00a1a2e4e
osquery itself does not care about unicode validity in table columns,
just takes it "as is". It definetely makes sense, because it could be broken.
But thrift extensions interface for python do it.
If, for instance, shell history contains broken unicode test `python_test_example_queries`
will fail.
```bash
% sed -n '5277p' < ~/.zsh_history | xxd -b [146]
00000000: 11000011 10000011 10111111 01101100 01110011 00001010 ...ls.
```
