site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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: In this case, ps is no more wrong than anything else. The KAuth API would give an absolute path AFAIK. = Mike _______________________________________________ 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... 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. The KAUTH API is useless here; there is no association between the authorisation check for executability on a vnode (where you would be able to fetch the looked-up path for the vnode) and a process which just *happens* to be associated with a task which just *happens* to have the text segment from said file mapped in a fashion consistent with a binary being executed. There is no guarantee that a process is a result of launching an executable. There is no guarantee that any file mapped into the task address space associated with a process has anything to do with the path given to the exec(2) system call. There is no guarantee that there even *was* an exec(2) system call. On Jan 4, 2006, at 1:47 PM, Terry Lambert wrote: 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. This is one facet of the issue; it's a specific instance of a generic problem. 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. I was actually referring to the comparatively low overhead of running ps vs. displaying UI, but the above is also good point. Note that it's important to specify the minimal set of fields for ps to display, as some symbolic information may result in nested network traffic leading to deadlock. This email sent to site_archiver@lists.apple.com