Re: Kernel NKE projects user space daemon.
Re: Kernel NKE projects user space daemon.
- Subject: Re: Kernel NKE projects user space daemon.
- From: Terry Lambert <email@hidden>
- Date: Thu, 5 Jan 2006 16:53:58 -0800
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.
Then having it available becomes a prerequisite for your software.
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)).
Welcome to the world of systems tools.
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden