Re: Kernel NKE projects user space daemon.
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Le 04 Jan 2006, à 08:27, Mike Smith a écrit : On Jan 3, 2006, at 12:14 PM, matt jaffa wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... So my NKE gets the pid of the process sending information out. I send this pid to a daemon that will lookup that process path based on the pid using the sysctl KERN_PROC methods. But this sysctl will fail if it is looking up the path on a process owned by root. So my daemon has to be running as root to get this info, and I want to be able to have a daemon for each logged in user so the UI can be displayed to the current active user. I could spawn a process with popen ( ps ) and gather the path that way, but ps will be spawned everytime I get a new pid my NKE doesn't know about. Is this a bad thing? Spawning a lot of little "ps" just to get this information. Don't use popen, as it invokes the shell and that puts you at risk (the shell may be invalid, or its startup files may have been coopted). However, given that you're about to draw UI and block waiting for the user, running ps (use a custom output format to override any defaults, and invoke ps via an explicit path) is not going to cause any observable overhead. Even if your application supports saved rules, running ps once per application is not a major hit. ps can still be wrong, but it is more likely to both be right and to be maintained in such a fashion that it prints reasonable output. I would say that ps is _always_ wrong when the process has been launched using a relative path since a relative path can match multiple absolute paths. As for the suid thing, why not just used a StartupItem or a launchd thing? Bootstrap context is usually the nirvana for daemon needing to communicate with a kernel extension. This email sent to site_archiver@lists.apple.com
participants (1)
-
Stephane Sudre