Re: Kernel NKE projects user space daemon.
Re: Kernel NKE projects user space daemon.
- Subject: Re: Kernel NKE projects user space daemon.
- From: Mike Smith <email@hidden>
- Date: Wed, 4 Jan 2006 19:43:40 -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 KAUTH API is useless here; there is no association between the
authorisation check for executability on a vnode (where you would be
able to fetch the looked-up path for the vnode) and a process which
just *happens* to be associated with a task which just *happens* to
have the text segment from said file mapped in a fashion consistent
with a binary being executed.
There is no guarantee that a process is a result of launching an
executable. There is no guarantee that any file mapped into the task
address space associated with a process has anything to do with the
path given to the exec(2) system call. There is no guarantee that
there even *was* an exec(2) system call.
On Jan 4, 2006, at 1:47 PM, Terry Lambert wrote:
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.
This is one facet of the issue; it's a specific instance of a generic
problem.
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.
I was actually referring to the comparatively low overhead of running
ps vs. displaying UI, but the above is also good point. Note that
it's important to specify the minimal set of fields for ps to
display, as some symbolic information may result in nested network
traffic leading to deadlock.
= Mike
_______________________________________________
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