RE: IPC between daemon -> non root app?
RE: IPC between daemon -> non root app?
- Subject: RE: IPC between daemon -> non root app?
- From: Philip Lukidis <email@hidden>
- Date: Tue, 15 Nov 2005 13:07:50 -0500
OK, if I have issues with CFNotificationCenter/CFSocket I'll try looking for
the list you mention.
thanks,
Philip Lukidis
> -----Original Message-----
> From: Dave Zarzycki [mailto:email@hidden]
> Sent: Tuesday, November 15, 2005 12:41 PM
> To: Philip Lukidis
> Cc: email@hidden
> Subject: Re: IPC between daemon -> non root app?
>
>
> Given some of the things you've just mentioned, I think sending an e-
> mail to one of the IOKit mailing lists would probably help you along
> much better and faster than I ever could (I don't work on those
> technologies).
>
> Good luck,
>
> davez
>
> On Nov 15, 2005, at 8:48 AM, Philip Lukidis wrote:
>
> > Thanks for your answer.
> >
> > I never intentionally initiated communication from the
> daemon to the
> > user
> > app. The CFMessagePort was setup as a direct result of a specific
> > request
> > from the user app. This, at first sight at least,
> communication is
> > always
> > initiated by the client user app. However, I do admit that
> I need the
> > daemon to notify the user app of interesting changes if the
> user app
> > so
> > requested, like hardware plug/unplug events, change in the
> hardware
> > state,
> > etc. I thought that a client request CFMessagePort would be the
> > answer.
> > Given my need of the daemon having to notify a "registered"
> user app
> > of
> > interesting events, how should I best proceed? If no user
> is logged
> > on,
> > then the user app will never request to be notified of interesting
> > events.
> > Each instance of the user app may request a new port to be
> setup, so I
> > assume this should take of multiple users.
> >
> > Would the CFNotificationCenter type suit my needs? Or am I
> going in
> > the
> > wrong direction entirely?
> >
> > thanks,
> >
> > Philip Lukidis
> >
> >> -----Original Message-----
> >> From: Dave Zarzycki [mailto:email@hidden]
> >> Sent: Tuesday, November 15, 2005 11:44 AM
> >> To: Philip Lukidis
> >> Cc: email@hidden
> >> Subject: Re: IPC between daemon -> non root app?
> >>
> >>
> >> That is intentional. What you are running into is how we
> >> organize our
> >> Mach bootstrap namespaces.
> >>
> >> You need to refactor your code such that communication is _always_
> >> initiated from a client living within a user's login session.
> >> A daemon
> >> should never try to initiate communication _to_ a user. A daemon
> >> should only answer requests from processes within sessions.
> >>
> >> Be prepared for the fact that:
> >>
> >> 1) More than one user may be logged in at once.
> >> 2) No user may be logged in at all.
> >> 3) Don't assume that only one user session is active at a time.
> >>
> >> If you have any follow up questions, please don't hesitate to
> >> ask them.
> >>
> >> davez
> >>
> >> On Nov 15, 2005, at 8:29 AM, Philip Lukidis wrote:
> >>
> >>> Hello, I'm having problems establishing IPC communication
> >> between my
> >>> test
> >>> daemon and a non root app (which for now is a plugin).
> The means of
> >>> communication is CFMessagePort. My app has no problem
> >> sending data
> >>> to the
> >>> daemon, but my daemon cannot open a remote port which the
> >> application
> >>> created. When I run the daemon under my username (and is thus not
> >>> run under
> >>> root), the daemon can open the remote port which my app
> >> created with
> >>> no
> >>> problems, and send notifications.
> >>>
> >>> Does anyone have any idea what is behind this? Is it a matter of
> >>> permissions? How could this be overcome?
> >>>
> >>> thanks for any ideas,
> >>>
> >>> Philip Lukidis
> >>> _______________________________________________
> >>> Do not post admin requests to the list. They will be ignored.
> >>> Darwin-dev mailing list (email@hidden)
> >>> Help/Unsubscribe/Update your Subscription:
> >>>
> >
> >>
> >> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden