-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Describe user-context-related caveat for screenlock table #7649
Describe user-context-related caveat for screenlock table #7649
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zhumo @directionless This only adds a warning to pass the user as a constraint, but the table is not actually implementing the logic.
Yikes. I won't know how to do that. So does this mean we don't need this doc change and the table is working fine as is? Or does this mean, someone should implement this functionality in the table? |
Well, I think it's a matter of what is the expected behavior? |
This table is kinda magic, I think we documented it in the original PR. Basically, the underlying library needs to run in a user's context. And the only way we've found to get it, is |
Oh I see, I realize now that I did the test incorrectly, because I was not running osquery via launchd, which I presume is what causes the issue, but I was launching it from terminal or using sudo. I know we currently have some functionality that attempts to "drop" privileges (and sometimes actually change the osquery user to another user, not nobody), but it doesn't seem to fully work on macOS, only the |
Dunno. |
It sounds like this PR may not improve the confusion around user context-specific tables. Does someone want to open a blueprint issue and maybe it can be added to the table specs or highlighted somehow in a new way? The user-context-specific problem is a big one for osquery but maybe there's a way to make it less confusing for users. |
c1a3a90
to
d8f080c
Compare
Alright, I tried one more time to capture somewhat tersely what was discussed above. |
@Smjert @directionless Hello! wanted to ping you all again here... WDYT? |
Closing and reopening to update the CI logic. |
Problem
Since Apple locked down the screenlock data, Kollide and osquery implemented a workaround (https://www.kolide.com/blog/how-kolide-built-its-macos-screenlock-check). The screenlock table is only for the current user context, but the table spec did not add the user_data=True attribute to reflect it. This PR adds that attribute.