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.
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:
A. You want your agent to run as root so that the user can't kill it.
B. Your agent must display GUI.
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.
Let's take a step back and look at your original request:
At 11:45 -0700 17/8/07, Eric Long wrote:
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.
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:
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.
$ killall UserNotificationCenter
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/email@hidden
