@Stefano Bonicatti I am working on a new table that uses a macOS API that only returns data for the current user only. If osquery is running as a daemon, the current user is usually root, which causes the returned data to not be useful. So what I was thinking of doing was when I need to run my code, to fork the osquery process, then in the new process drop privileges into the specified user from the query context, run the query, and then use some kind of IPC mechanism to get the data back to the parent osquery process and then kill the child. It seems https://github.com/osquery/osquery/pull/6209 does some similar things. Do you think copying these patterns is the way to go or is there a better way in your opinion to accomplish the above?

Yeah, It would've required different performance characteristics also, especially with JOIN and index columns

Got it

I hope that works for your use cases. I can see the OS implementing something more than a euid check to determine if you can perform an action as a user.

I hope so too!

@theopolis I’ve found out the hard way that just dropping the euid per thread is not enough. on macOS a lot of these checks are relying on the launchagent context. you’ll get totally different behavior with sudo osquery vs with osquery in launchd

lol, why was it a waste?

it did not

so annoying

yeah, so how are you going to implement that in osquery core?

oh yeah that's game over

and it’s still problematic from the API because it’s leaky. You’d assume osquery returns all the info for all users, not just the currently logged in one.

yeah that limitation just needs to be accepted

I think having an extension with a separate process and XPC between might work

and documented

come to think of it I have enough swift chops these days to implement a user “agent” that exposes some of these hard to check values. It would run as it’s own process and an extension can query the values from it

problem is now you have another binary to distribute to folks

yes

they never disappoint

Are you sure you tested setting euid/ruid enough? I would dtrace what is happening and see if you can isolate the auth failure. I’ve never investigated dropping a thread’s permissions completely (overwriting suid) but check if that works/is possible too

@theopolis here is the trivial program I am using to test this...

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[])
{
   pthread_setugid_np(501, 20)
   NSUserDefaults * userDefaults = [[NSUserDefaults alloc] initWithSuiteName:@"com.apple.sharingd"];
   NSDictionary * dict = [userDefaults dictionaryRepresentation];
   NSLog(@"%@", dict);
   return 0;
}

gcc -framework Foundation test.m -o test

and run it with

sudo launchctl asuser 0 ./test

I get the settings for UID 0 not 501. If instead of

pthread_setugid_np(501, 20)

I use

seteuid(501); setegid(20)

and run it with the same arguments, it logs the correct settings.

This is a long shot but can you call the macOS pthread API then spawn another thread, check your uid/gid, then try the user defaults request?

I'll give it a shot, and let you know