site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Then having it available becomes a prerequisite for your software. Welcome to the world of systems tools. -- 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 5, 2006, at 2:26 AM, Stephane Sudre wrote: On 04 Jan 2006, at 22:47, Terry Lambert wrote: 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. It's not a supported API, it is an SPI. Applications are not intended to use it. System utilities are permitted to use it, so long as they are revised in lockstep with the base OS. Applications - no matter *who* writes them - are expected to talk to the system utilities, and get the information in a nice, safe, abstract, and nominally future- proof way, instead of going fishing. Any other use of it is "at your own substantial risk of your software breaking, maybe as soon as the next software update", and strongly discouraged. 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. This is true; however, this complaint is almost completely mitigated by the fact that there are international and defacto standards for the "ps" program, and as long as neither of those standards change, you can be pretty darn sure that standards conforming use of the program will continue to work as expected. The reason we suggested that you use specific output formatting and process-of-interest constraint options, rather than groveling through the default unqualified and unconstrained output, was *specifically* to insulate you from potential changes to those standards or the tool's output outside the scope of control of standards, or any bug fixes we might have to do. An extreme case could also be that the ps tool is not installed on the computer. This may be inconvenient, but it's less inconvenient than, say, needing to install your application as SUID root, like "ps" itself, or your SUID application crashing or being used as a gateway to compromise system integrity, or dozens of other worse things than having "ps" available to people who already have shell access to the machine. 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)). There really isn't any UNIX or UNIX-like system in existence that doesn't have some form of data interface that requires changes to system utilities, or user applications that think (or act like) they are system utilities. This includes things like the ill-designed "procfs" on many systems. And if an administrator takes away "ps", they will surely take away "/proc", so that people can't write or download their own copy of "ps" to override the administrators decision, unless "/proc" is also disabled - at which point you are in the same boat. The bottom line is that, if you insist on using data interfaces - even supported ones, which these are not - instead of using procedural interfaces to talk to programs that use data interfaces, to insulate yourself from any unforeseen OS changes... well, you are probably going to eventually be unhappy when your application suddenly stops working. 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? Using it or launching a helper tool that uses it from the bootstrap session is unsupported. If you think about it, it should be obvious to you why this is the case. This email sent to site_archiver@lists.apple.com