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: Wed, 4 Jan 2006 13:47:45 -0800
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.
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.
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.
As for the suid thing, why not just used a StartupItem or a
launchd thing? Bootstrap context is usually the nirvana for daemon
needing to communicate with a kernel extension.
As Matt clearly pointed out, he needs to present UI to the user;
this can't be done legitimately from the bootstrap session. And it
doesn't help solve this problem.
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".
-- 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