Re: KUNCUserNotificationCallBack
Re: KUNCUserNotificationCallBack
- Subject: Re: KUNCUserNotificationCallBack
- From: Eric Long <email@hidden>
- Date: Tue, 21 Aug 2007 08:44:48 -0700
- Thread-topic: KUNCUserNotificationCallBack
> aunchd 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.
Ok. My misunderstanding.
> 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.
I understand why a GUI agent cannot run as root and I accept that.
My software protects a user's data from being copied, while at the same time
permitting an authorized user to have the privilege.
If the agent is picked off and I can't communicate, I can't authorize. If I
can't authorize, I can't allow privileges, nor can I explain why things are
in this state to the user.
It's possible the "bad guy" might be smart enough to re-launch the agent to
avoid obvious detection, before the user returns, but if not, things will
just be silently locked down when the user returns.
In the initial email on this topic, I was hoping I could actually authorize
from the kernel to end the lockdown, but it was quickly pointed out that I
can't do that. I then turned the discussion towards posting any kind of
alert from the kernel.
My thinking was to log all anomalies, so there's a record of events, and
post periodic timed alerts until the problem is dealt with, so we can inform
the user how to end the lockdown. But apparently I can't do that either.
> 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.
You mentioned this earlier. I'm a little fuzzy on the premise.
Are you suggesting that my daemon, which is run as root, could interact with
this to get GUI to display indirectly in the current user's log-in session?
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden