site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com 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:zarzycki@apple.com] Sent: Tuesday, November 15, 2005 12:41 PM To: Philip Lukidis Cc: darwin-dev@lists.apple.com 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:zarzycki@apple.com] Sent: Tuesday, November 15, 2005 11:44 AM To: Philip Lukidis Cc: darwin-dev@lists.apple.com 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription:

http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com

...

...

This email sent to zarzycki@apple.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com