Re: Kernel NKE projects user space daemon.
Re: Kernel NKE projects user space daemon.
- Subject: Re: Kernel NKE projects user space daemon.
- From: Herb Petschauer <email@hidden>
- Date: Thu, 5 Jan 2006 18:33:06 -0800
On 1/5/06, Terry Lambert <email@hidden> wrote:
> 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
> _______________________________________________
Delurk:
see my current favourite tech note, aka "argh, where were you a few
years ago but we figured it out",
<http://developer.apple.com/technotes/tn2005/tn2083.html>
-H.
Lurk:
_______________________________________________
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