site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 04 Jan 2006, at 22:47, Terry Lambert 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... 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. So it's basically a snapshot, however you approach it. Affirmative, but I would rather get an absolute snapshot than a relative one. 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. I agree that the sysctl thing is a problem since for instance the ps code using sysctl from Panther is not working on Tiger. 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. Yet the problem with using ps is that you are relying on an external tool which may change in the future and to which you do not have access as changes are being made. Example: the ps source code for Tiger was not available until the release of Tiger. An extreme case could also be that the ps tool is not installed on the computer. Anyway, the main problem IMHO is that OS X/Darwin is lacking either a true and trustful API to get this information or a proc folder (even though I think I saw such a folder in one case (maybe it was on OS X Server)). 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". I'm not sure to see where the illegitimate part lies in the CFUserNotification API or launching a helper tool. Can you shed some light on this? This email sent to site_archiver@lists.apple.com