site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com What I'm saying is, launchd runs as root. You cannot kill launchd without authenticating. I have an agent that runs as it should in each user session, not as root. Someone could maliciously kill my agent to circumvent the protection system it is a part of. launchd is extremely fast at relaunching it. I know it will get relaunched if I can use launchd, unless someone with root access gets involved trying to kill it. So, I expect to be able to post UI through it at some instance. A. You want your agent to run as root so that the user can't kill it. B. Your agent must display GUI. Let's take a step back and look at your original request: I see a documented example of using KUNCUserNotificationDisplayFromBundle to display an authentication dialog from a kext. I want to use this functionality in case my daemon or agent gets into trouble somehow, and I need to give the user some options. In my KUNCUserNotificationCallBack, after I get the user's name/password, how do I validate that this is a user name and password for a user with admin privileges? I haven't been able to find the way to do this in the kernel. $ killall UserNotificationCenter S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 8:28 -0700 20/8/07, Eric Long wrote: OK, the above shows a misunderstanding that I need to correct before going any further. launchd agents are run by a per-user launchd. That per-user launchd is owned by the user. Thus, the user can muck with that instance of launchd as much as they like. The root launchd /is/ owned by root, but it is not involved in launching agents. The above is true on Mac OS X 10.4.x and future system software. The design goal is to reduce the risk of privileges leaking from the root launchd into an agent.

From looking at the rest of your post, it seems that you're at a fundamental impasse: C. Apple does not want GUI programs running as root because it's a security hole. We don't do this on our system, and we recommend that you not do it either. At 11:45 -0700 17/8/07, Eric Long wrote:

How do you think KUNCUserNotificationDisplayFromBundle is implemented? Well, it turns out that the GUI is displayed by an agent. The actual implementation is very scary and likely to change in the future, but the take home point is that the program displaying the dialogs is run as the user who is currently logged in on the console. You can see this by posting a notification and then running Quartz Debug to see which process opened that window. You'll see that it's "UserNotificationCenter". You can then run: $ ps -o uid,ruid,gid,rgid,ucomm -p `killall -s UserNotificationCenter | cut -d ' ' -f 3` UID RUID GID RGID UCOMM 2000 2000 2000 2000 UserNotification to see the EUID, RUID, EGID, and RGID of the process. Lo, it's you! And if you want the notification to go away, just kill it. The only way that I can think of to get GUI displayed in a way that can't be interfered with by a user (this is, without them explicitly authenticating as admin) is via an authorisation plug-in. Authorisation plug-ins are hosted by a process ("SecurityAgent") that can display GUI but is run by a user that's distinct from all logged in users ("securityagent"). And it's no coincidence that Mac OS X's passwords dialogs are brought up by this process. It's possible that you could construct a fully bulletproof solution using this mechanism, but I can't be sure without evaluating the issue in a lot more detail. This email sent to site_archiver@lists.apple.com