Re: Kernel NKE projects user space daemon.
Re: Kernel NKE projects user space daemon.
- Subject: Re: Kernel NKE projects user space daemon.
- From: Brian Bergstrand <email@hidden>
- Date: Tue, 3 Jan 2006 16:09:16 -0600
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jan 3, 2006, at 3:47 PM, Mike Smith wrote:
On Jan 3, 2006, at 12:40 PM, Brian Bergstrand wrote:
On Jan 3, 2006, at 8:31 AM, matt jaffa wrote:
I have a NKE project that needs a user space daemon to be
running to get information back from the user.
I have this working and everything, and have a daemon launched
for each individual user that runs the program.
I have my user space daemon with these privileges, 4755, which
means the setuid bit is set for my daemon executable so that it
can elevate itself to perform a process id lookup. My question
is what does Apple/Security feel about my application having the
setuid bit set?
I'm a little confused about "perform a process id lookup"
though. What are you trying to do, and what specific interface
(s) are you using that require privilege?
I think he means that KERN_PROCARGS returns an error when you try
to get info about processes running with a different uid than the
calling application (unless you are root). In my case I only care
about the full exec path and not the program args.
You should not depend on any path information associated with a
running process.
However, KERN_PROC_PID can be used to get the process struct of
any process from a non-root app and the kp_proc.p_comm member will
give you a limited name (16 bytes and not the full path). The full
path is very useful for use as an arg to LSCopyDisplayNameForURL
(), but pcomm suffices as a fall back.
Is there some other way for a non-root process to get the full
exec path of any other process (including root owned)?
No. In addition, there is no guarantee that the path is correct,
that the file that is present at that path is the one being
executed, that the path is acccessible or even valid for your
context, or that there even was a path to begin with.
Any information you get from p_comm or the KERN_PROCARGS sysctl is
purely informative, and you should not depend on it in any fashion
whatsoever.
If you need a guaranteed association between running processes and
filesystem identities you need to look at a higher level, and
accept that there are processes and tasks which will fall outside
the scope of the information available at that level.
= Mike
I know and accept all of that - for my app, the information is purely
informative to the user. There are no permanent associations/
assumptions made about the path. It's that pcomm can contain a
truncated name and the user (not my app) may not be able to associate
the truncated name with an actual application. Most of the time,
pcomm suffices so it's not a big problem.
Brian Bergstrand
<http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDuvYRedHYW7bHtqIRArrSAJsH/QHXcEbDEy7eBj6ef1COeN3H7gCeKqK5
/X8vro2VcXhPjgZqso2umlE=
=y86Y
-----END PGP SIGNATURE-----
_______________________________________________
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