November 2005 - Darwin-dev - lists.apple.com

RE: IPC between daemon -> non root app?
by Philip Lukidis 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thankfully, I'm only concerned with 10.3 and above. thanks, Philip Lukidis > -----Original Message----- > From: Stephane Sudre [mailto:ssudre@intego.com] > Sent: Tuesday, November 15, 2005 12:59 PM > To: Philip Lukidis > Cc: 'darwin-dev(a)lists.apple.com' > Subject: Re: IPC between daemon -> non root app? > > > > On 15 Nov 2005, at 17:49, Philip Lukidis wrote: > > > Would CFNotificationCenter work? Or CFSocket? I'll read up about > > these > > types. > > > > thanks, > > I've been using CFDistributedNotification or > NSDistributedNotification > for 4 years and it has been working fine for the project I'm working > on. > > The only caveat I've been told about this is that on Mac OS X > 10.2, the > object of the distributed notification can be nil when you > receive it. > But that's not a problem since I'm using the userInfo. > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: IPC between daemon -> non root app?
by Philip Lukidis 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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(a)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(a)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(a)lists.apple.com) > >>> Help/Unsubscribe/Update your Subscription: > >>> > > > http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com > >> > >> This email sent to zarzycki(a)apple.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: IPC between daemon -> non root app?
by Stephane Sudre 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 15 Nov 2005, at 17:49, Philip Lukidis wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Would CFNotificationCenter work? Or CFSocket? I'll read up about these types. thanks, I've been using CFDistributedNotification or NSDistributedNotification for 4 years and it has been working fine for the project I'm working on. The only caveat I've been told about this is that on Mac OS X 10.2, the object of the distributed notification can be nil when you receive it. But that's not a problem since I'm using the userInfo. This email sent to site_archiver(a)lists.apple.com

1 0

Re: IPC between daemon -> non root app?
by Dave Zarzycki 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Good luck, davez On Nov 15, 2005, at 8:48 AM, Philip Lukidis wrote: Thanks for your answer. 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(a)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: test daemon and a non root app (which for now is a plugin). The means of communication is CFMessagePort. My app has no problem to the daemon, but my daemon cannot open a remote port which the 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 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.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). 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? Hello, I'm having problems establishing IPC communication between my sending data application created with http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com This email sent to zarzycki(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mach message format/structure
by Kevin Van Vechten 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com - Kevin On Nov 14, 2005, at 10:28 PM, Rob Ballantyne wrote: I'm trying to use the mach_msg interface to pass around messages between two userland tasks. I'm having trouble with the calls to mach_msg complaining about an 'invalid msg-header' when I try to associate a local_port (and port_right?) with the message so that the server can respond. If I set local_port to MACH_PORT_NULL I can send to the server, setting it to anything other than that gives me the invalid msg-header error. Is it possible with out setting the MACH_MSGH_BITS_COMPLEX to enable a server response or does the entire message transaction have to be of the 'complex' type to send a send-right to the server process? Is there documentation on the mach_msgh_bits field of the header? I've got the mach_msg_header.html document in xnu-*/osfmk/man and it describes the bits but doesn't talk about appropriate use of them. Is there anything that talks about correct use of the bit fields? Finally, does anyone have a good example of a non-MIG server that demonstrates much of what I've mentioned above? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… CFMessagePort is a good example of using mach_msg for round-trip communication. <http://www.opensource.apple.com/darwinsource/10.4.3/CF/ RunLoop.subproj/CFMessagePort.c> This email sent to site_archiver(a)lists.apple.com

1 0

Re: IPC between daemon -> non root app?
by plumber 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks for your answer. thanks, thanks, CFSocket http://developer.apple.com/samplecode/CFLocalServer/CFLocalServer.html CFNotificationCenter http://lists.apple.com/archives/Cocoa-dev/2003/Jan/msg01994.html Best Regards _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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? Philip Lukidis Would CFNotificationCenter work? Or CFSocket? I'll read up about these types. Philip Lukidis This email sent to site_archiver(a)lists.apple.com

1 0

RE: IPC between daemon -> non root app?
by Philip Lukidis 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Would CFNotificationCenter work? Or CFSocket? I'll read up about these types. thanks, Philip Lukidis > -----Original Message----- > From: Stephane Sudre [mailto:ssudre@intego.com] > Sent: Tuesday, November 15, 2005 11:41 AM > To: Philip Lukidis > Cc: 'darwin-dev(a)lists.apple.com' > Subject: Re: IPC between daemon -> non root app? > > > > On 15 Nov 2005, at 17:29, 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? > > It's the usual "we do not share the same context problem". > > AFAIK, you can not send a CFMessagePort from a (bootstrap) > daemon to a > user land process. > > Distributed notifications may be a solution (be sure to allow the > notification to walk through all user sessions), named pipes too or > socket probably. > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: IPC between daemon -> non root app?
by Philip Lukidis 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com 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(a)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(a)lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com > > This email sent to zarzycki(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: IPC between daemon -> non root app?
by Dave Zarzycki 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com 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: 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.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. 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. This email sent to zarzycki(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: IPC between daemon -> non root app?
by Stephane Sudre 15 Nov '05

15 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 15 Nov 2005, at 17:29, Philip Lukidis wrote: Does anyone have any idea what is behind this? Is it a matter of permissions? How could this be overcome? It's the usual "we do not share the same context problem". _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. AFAIK, you can not send a CFMessagePort from a (bootstrap) daemon to a user land process. Distributed notifications may be a solution (be sure to allow the notification to walk through all user sessions), named pipes too or socket probably. This email sent to site_archiver(a)lists.apple.com

1 0