Re: Kernel NKE projects user space daemon.
Re: Kernel NKE projects user space daemon.
- Subject: Re: Kernel NKE projects user space daemon.
- From: Stephane Sudre <email@hidden>
- Date: Thu, 5 Jan 2006 11:26:54 +0100
On 04 Jan 2006, at 22:47, Terry Lambert wrote:
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?
_______________________________________________
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