site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com So it's basically a snapshot, however you approach it. -- Terry _______________________________________________ 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... On Jan 4, 2006, at 9:34 AM, Stephane wrote: On Jan 4, 2006, at 5:58 PM, Mike Smith wrote: On Jan 4, 2006, at 2:58 AM, Stephane Sudre wrote: 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. In this case, ps is no more wrong than anything else. The KAuth API would give an absolute path AFAIK. The approach I described using a kauth listener to get the path information depends on the directory lookup name cache information. The problem with this approach, which I think Mike is alluding to, is that between the time you cache the information in the user space daemon, and he time you use it to present to the user a choice, the target of the path that was cached may have changed. Even if you specifically go out of your way in user space, and also pass dev_t and ino_t information, verifying it immediately before presentation in the UI -- there's no real way to programatically lock a path so that its components are not permitted to change, without seriously obstructing the ability of the system to get actual work done. Using the output of the "ps" program is actually the recommended method of getting information which is the least prone to breakage in future versions of the OS going forward. For the most part, I personally hate the KERN_* sysctl's - they are data interfaces, and therefore subject to becoming potentially stale. If you use the output of "ps" with appropriate field selection arguments to get only the data you want, then we can change things out from under you, and your application will still work, since "ps" is revised in lockstep with the kernel itself. As Mike also pointed out in another message, "ps" is OK for this particular case, since the issue only comes up when specific network traffic is being allowed/denied via a user interaction. The "ps" program itself won't trigger this in the normal case, since it's run from local disks, and has no network dependencies of its own. 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. As Matt clearly pointed out, he needs to present UI to the user; this can't be done legitimately from the bootstrap session. And it doesn't help solve this problem. This can be done from a bootstrap session. You just have to launch a helper tool for the UI. If the UI does not need to be really complex, you can also use a CFUserNotification dialog. We discourage this - "...can't be done *legitimately*..." [emphasis mine] - because you never know that what happens to work right now will continue to work the same way in some far off future. There's a big difference between "can be done this way" and "should be done this way". This email sent to site_archiver@lists.apple.com