Describe user-context-related caveat for screenlock table

[zhumo]

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.

[Smjert]

@zhumo @directionless This only adds a warning to pass the user as a constraint, but the table is not actually implementing the logic.

Apparently not!

[zhumo]

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?

[Smjert]

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?
On my macbook with 12.4 this seems to work fine, I can see it detect it's enabled and the grace period is 0, but was the expectation that one could read the settings for another user on the same machine or?
This is totally missing from the table (and anyway, it seems from your report that this is not possible anymore anyway).

[directionless]

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 launchd runas. So there's no simple way, inside osquery, to pass a uid in.

[Smjert]

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 launchd runas. So there's no simple way, inside osquery, to pass a uid in.

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.
There's something similar on Windows where there are some registry hives (of other users) that you cannot access unless you're logged in with that user.

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 gid gets changed, and the uid remains root (0).
I wonder if there's another way and if that would somehow solve the issue, or if you really need something else to be initialized as that user.

[directionless]

I wonder if there's another way and if that would somehow solve the issue, or if you really need something else to be initialized as that user.

Dunno. launchd runas was the only thing we found. The user also has to have been recently logged in, so the underlying data is decrypted and available

[mike-myers-tob]

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.

[zhumo]

Alright, I tried one more time to capture somewhat tersely what was discussed above.

My concerns have been resolved

[zhumo]

@Smjert @directionless Hello! wanted to ping you all again here... WDYT?

[Smjert]

Closing and reopening to update the CI logic.