CFPreferences problem with user scripts

[jessepeterson]

When using LoginScriptPlugin with a script running as a user that modifies CFPreferences (happens to be a script using pyobjc CFPreferencesApp* APIs) I'm getting odd results that are probably related to cfprefsd caching. I see that there's a warning saying #warning REVIEW: User commands still run in root's session. Perhaps it's related to that. I note that if I kill the (root-running) cfprefsd then my script mostly does the correct thing (running as a postmount-user-* script) in limited testing, but when not doing this the CFPreferencesApp* APIs return stale data.

[jessepeterson]

As an aside it looks like the documentation suggests changing the UID using pthread_setugid_np but the code currently just uses setuid. When checking my script it appears to be running as UID and EUID of the correct user, so in theory it should be okay. Apple says this on that:

One process-wide value that deserves special attention is the effective user ID (EUID). There are circumstances where your authorization plug-in should switch the EUID to that of the user logging in. In these circumstances you should avoid using seteuid, because it modifies the EUID for the entire process. Rather, you should use the per-thread alternative, pthread_setugid_np; Listing 5 shows an example of how to use this routine.

Of course by that point in the code we're already forked and in our own process space so the above isn't so relevant.

[jessepeterson]

Oh, and perhaps the most pertinent piece of information: if I run my script in the user session it works as it should. Correctly reading and writing the correct non-cached CFPreferencesApp* APIs as it looks like the other applications use.

[jessepeterson]

Finally, for the time being I've created another script postmount-root-kill-cfprefsd.sh which simply issues a "killall cfprefsd" as root. This allows the script to function as I would expect. My CFPreferencesApp* calls get and return the "correct" non-cached data.

I'll also note that El Capitan 10.11b8 does not appear to exhibit this issue.

[MagerValp]

Is this still an issue? If so do you have a minimal test case I could try? Is there any change with 1.0b32?